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Intellectual Property Rights 

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in SR 000 3 14: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect 
of ETSI standards", which is available free of charge from the ETSI Secretariat. Latest updates are available on the 
ETSI Web server (http://www.etsi.org/ipr). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in SR 000 314 (or the updates on the ETSI Web server) 
which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by the Special Mobile Group (SMG). 

The present document describes the functionality of charging in GPRS needed to support the first phase of GPRS within 
the digital cellular telecommunications system. 

The contents of the present document is subject to continuing work within SMG and may change following formal SMG 
approval. Should SMG modify the contents of the present document, it will be re-released by SMG with an identifying 
change of release date and an increase in version number as follows: 

Version 7.x.y 

where: 

7 indicates GSM Phase 2+ Release 1998; 

X the second digit is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc.; 

y the third digit is incremented when editorial only changes have been incorporated in the specification. 
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1 Scope 

The GSM PLMN supports a wide range of voice and non-voice services in the same network. In order to enable 
operators the abiUty to provide a commercially viable service there is a need to provide charging functions. The present 
document describes the functionality of charging in GPRS needed to support the first phase of GPRS, as defined in 
GSM 02.60[3] and GSM 03.60[8] (packet based services). 



2 References 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of pubUcation, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

• A non-specific reference to an ETS shall also be taken to refer to later versions pubUshed as an EN with the same 
number. 

• For this Release 1998 document, references to GSM documents are for Release 1998 versions (version 7.x.y). 

[I] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and 
acronyms". 

[2] GSM 01.61: "Digital cellular telecommunications system (Phase 2+); GPRS ciphering algorithm 

requirements". 

[3] GSM 02.60: "Digital cellular telecommunications system (Phase 2-I-); General Packet Radio 

Service (GPRS); Service description; Stage 1". 

[4] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and 

identification". 

[5] GSM 03.07: "Digital cellular telecommunications system (Phase 2+); Restoration procedures". 

[6] GSM 03.22: "Digital cellular telecommunications system (Phase 2+); Functions related to Mobile 

Station (MS) in idle mode and group receive mode". 

[7] GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical reaUzation of the 

Short Message Service (SMS); Point-to-Point (PP)". 

[8] GSM 03.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Service description; Stage 2". 

[9] GSM 03.61: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Point to Multipoint Multicast Service Description; Stage 2". 

[10] GSM 03.62: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Point to Multipoint Group Call Service Description; Stage 2". 

[I I] GSM 03.64: "Digital cellular telecommunications system (Phase 2+); Overall description of the 
General Packet Radio Service (GPRS) Radio interface; Stage 2". 

[12] GSM 04.07: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface 

signalling layer 3; General aspects". 

[13] GSM 04.08: "Digital cellular teleconmunications system (Phase 2+); Mobile radio interface layer 

3 specification". 
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[14] GSM 04.64: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Logical Link Control (LLC)". 

[15] GSM 04.65: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Subnetwork Dependent Convergence Protocol (SNDCP)". 

[16] GSM 08.08: "Digital cellular telecommunications system (Phase 2+); Mobile Switching Centre - 

Base Station System (MSC - BSS) interface: Layer 3 specification". 

[17] GSM 08.14: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; Gb 

interface layer 1". 

[18] GSM 08. 16: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN) interface; 
Network Service". 

[19] GSM 08.18: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); Base Station System (BSS) - Serving GPRS Support Node (SGSN); BSS GPRS 
Protocol (BSSGP)". 

[20] GSM 08.60: "Digital cellular telecommunications system (Phase 2+); Inband control of remote 

transcoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channels." 

[21] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part 

(MAP) specification". 

[22] GSM 09.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio 

Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface". 

[23] GSM 09.61: "Digital cellular telecommunications system (Phase 2+); General requirements on 

interworking between the Public Land Mobile Network (PLMN) supporting General Packet Radio 
Service (GPRS) and Packet Data Networks (PDN)". 

[24] CCITT Recommendations 1. 1 30: "General modelhng methods - Method for the characterisation of 

telecommunication services supported by an ISDN and network capabilities of an ISDN". 

L25J CCITT Recommendation E.164: "Numbering plan for the ISDN era". 

[26] CCITT Recommendation Q.65: "Methodology - Stage 2 of the method for the characterization of 

services supported by an ISDN". 

[27] CCITT Recommendation Q.922: "Digital subscriber signalhng system no. 1 (DSS 1) - Data link 

layer - ISDN data link layer specification for frame mode bearer services". 

[28] CCITT Recommendation Q.933: "Digital subscriber signalling system no. 1 (DSS 1) - Network 

layer - Signalling specification for frame mode basic call control". 

[29] CCITT Recommendation V.42 bis: "Data communication over the telephone network - Data 

compression procedures for data circuit-terminating equipment (DCE) using error correction 
procedures". 

[30] CCITT Recommendation X.3: "Packet assembly disassembly facihty (PAD) in a public data 

network". 

[31] CCITT Recommendation X.25: "Interface between data terminal equipment (DTE) and data 

circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to 
public data networks by dedicated circuit". 

[32] CCITT Recommendation X.28: "DTE / DCE interface for a start-stop mode data terminal 

equipment accessing the packet assembly / disassembly facility (PAD) in a pubhc data network 
situated in the same country". 

[33] CCITT Recommendation X.29: "Procedures for the exchange of control information and user data 

between a packet assembly / disassembly (PAD) facihty and a packet mode DTE or another PAD". 
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[34] CCITT Recommendation X.75: "Packet- switched signalling system between public networks 

providing data transmission services". 

[35] CCITT Recommendation X.121: "International Numbering Plan for Public Data Networks". 

[36] IETF RFC 768 (1980): "User Datagram Protocol" (STD 6). 

[37] IETF RFC 791 (1981): "Internet Protocol" (STD 5). 

[38] IETF RFC 792 (1981): "Internet Control Message Protocol" (STD 5). 

[39] IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7). 

[40] 1S08824 (90) / X.208 (88): "Information technology - open System Interconnection - 

Specification of Abstract Syntax Notation One (ASN.l)". 

[41] IS08824-1 (94) / X.680 (94): "Information technology - Abstract Syntax Notation One (ASN.l) 

- Specification of Basic Notation". 

3 Definitions abbreviations and symbols 

3.1 Definitions 



Refer to: GSM 02.60 [3]. 

In GSM 02.02 the bearer services are described. The general network configuration is described in GSM 03.02 and the 
GSM PLMN access reference configuration is defined in GSM 04.02. The various connection types used in the GSM 
PLMN are presented in GSM 03.10. Terminology used in the present document is presented in GSM 01.04 [1]. For 
support of data services between GSM PLMN and other networks see GSM 09-series of Specifications. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply. Additional applicable abbreviations can be 
found in GSM 01.04 [1]. 



APN 


Access Point Name 


BG 


Border Gateway 


BS 


Billing System 


BSS 


Base Station Subsystem 


CDR 


Call Detail RecordC-ID Charging ID 


CG 


Charging Gateway 


CGF 


Charging Gateway Functionahty 


GTP 


GPRS Tunnel Protocol 


CMIP 


Common Management Information Protocol 


FAV 


Firewall 


GGSN 


Gateway GPRS Support Node 


GPRS 


General Packet Radio Service 


G-CDR 


Gateway GPRS Support Node - Call Detail Record 


IHOSS:OSP 


Internet Hosted Octet Stream Service:Octect Stream Protocol 


IP 


Internet Protocol 


MS 


Mobile Station 


M-CDR 


Mobility Management - Call Detail Record 


NE 


Network Element 


NSS 


Network and Switching Subsystem 


NMG 


Network Management Gateway 


NMN 


Network Management Node 


OMC 


Operations and Maintenance Centre 


OSF 


Operations System Function 


OSP 


Octet Stream Protocol 
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PDN 


Packet Data Network 


PDP 


Packet Data Protocol, e.g., IP or X.25 


PLMN 


Public Land Mobile Network 


PPP 


Point to Point Protocol 


PSPDN 


Packet Switched Public Data Network 


PTM-M 


Point to Multipoint - Multicast 


PTM-G 


Point to Multipoint - Group Call 


PTM SC 


Point to Multipoint Service Centre 


RAC 


Routing Area Code 


SGSN 


Serving GPRS Support Node 


SNDCP 


Sub-Network Dependent Convergence Protocol 


SNMP 


Simple Network Management Protocol 


SS7 


Signalling System No. 7 


S-CDR 


Serving GPRS Support Node - Call Detail Record 



S-SMO-CDR SGSN delivered Short message Mobile Originated - Call Detail Record 
S-SMT-CDR SGSN delivered Short message Mobile Terminated - Call Detail Record 
TED Tunnel Identifier 

3.3 Symbols 

For the purposes of the present document, the following symbols apply: 
A Interface between an MSC and a BSC. 

Ga Charging data collection interface between a CDR transmitting unit (e.g. GGSN or SGSN) and a 

CDR receiving functionality (CGF). 

Gb Interface between an SGSN and a BSC. 

Gc Interface between an GGSN and an HLR. 

Gd Interface between an SMS-GMSC and an SGSN, and between a SMS-IWMSC and an SGSN. 

Gf Interface between an SGSN and an EIR. 

Gi Reference point between GPRS and an external packet data network. 

Gn Interface between two GSNs within the same PLMN. 

Gp Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS 
network services across areas served by the co-operating GPRS PLMNs. 

Gr Interface between an SGSN and an HLR. 

Gs Interface between an SGSN and an MSCA^LR. 

kbit/s Kilobits per second. 

R Reference point between a non-ISDN compatible TE and MT. Typically this reference point 

supports a standard serial interface. 

Um Interface between the mobile station (MS) and the GPRS fixed network part. The Um interface is 

the GPRS network interface for providing packet data services over the radio to the MS. The MT 
part of the MS is used to access the GPRS services through this interface. 
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4 Architecture 

The following figures 1 and 2 show the GPRS logical architecture and GPRS charging logical architecture. 



SMS-GMSC 
SMS-IWMSC 



MSC/VLR 



XGs 
Gb 



D 



IE 






MT 






BSS 



















SM-SC 



-Gd 



HLR 



Gr 



Gn 



-Gc 



Gi 





GGSN 










H 





Signalling Interface 
SignalUng and Data Transfer Interface 

Figure 1 : Overview of the GPRS Logical Architecture 

GPRS is logically implemented on the GSM structure through the addition of two network nodes, the Serving GPRS 
Support Node and the Gateway GPRS Support Node. No inference should be drawn about the physical configuration on 
an interface from Figure I . 
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Figure 2: GPRS charging logical architecture 



4.1 Charging Gateway Functionality 

The Charging Gateway Functionality (CGF) provides a mechanism to transfer charging information from the SGSN and 
GGSN nodes to the network operator's chosen Billing Systems (BS). The Charging Gateway concept enables an 
operator to have just one logical interface between the CGF and the BS. The CGF may be supported in one of the 
following ways:- 

as a centralised separate network element (Charging Gateway); 
as a distributed functionality resident in the SGSNs and GGSNs. 

Support of the centralised or distributed CGF in a network is implementation dependent, and subject to 
vendor/manufacturer agreement. Regardless of the way in which the CGF is supported in the network, the functionality 
of the CGF is similar. Figure 3 gives an overview of the two basic configurations: In scenario 1, the GSNs support an 
external interface to the charging gateways they are connected to. In scenario 2, the GSNs support the charging gateway 
functionality internally. 
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Scenario 1 : 

GSN 
1 



CG 



1 



CGF 








BS 



Scenario 2: 
GSN 





CGF 




RS 





Figure 3: Basic archiitectural scenarios for the CGF location 

If the GSNs with internal charging gateway functionality also support the external interface, additional configurations as 
shown in figure 4 are possible. In scenario 3, the GSN with integrated charging gateway function also acts as CGF for 
other GSNs. In scenario 4, the GSN with integrated charging gateway function also supports the transmission of CDRs 
to external CGFs. 



Scenario 3: 



GSN GSN 



1 




CGF 




BS 













Scenario 4: 
GSN CG 



CGF 




CGF 













Figure 4: Optional scenarios for the CGF configuration 



The above four scenarios are not exhaustive. 

The CGF provides the mechanism to transfer charging information from the SGSN and GGSN nodes to the network 
operator's chosen Billing Systems(s) (BSs). The main functions of the CGF are:- 

- the collection of GPRS CDRs from the GPRS nodes generating CDRs 
intermediate CDR storage buffering 
the transfer of the CDR data to the billing systems 

The CGF acts as a storage buffer for real time CDR collection. It provides the CDR data to the billing system. This 
specification identifies the external interfaces of the CGF, but does not specify the internal functionality of the CGF. 
However, in order to assist in the understanding of the CGF, it may perform specific activities, such as consolidation of 
CDRs, pre-processing of CDR fields, filtering of unrequired CDR fields, and adding of Operator defined fields for 
specific billing systems. These specific activities may be performed to optimise the charging information that is to be 
forwarded to the Billing System, which should reduce the load in the Billing System. 

In addition to the centralised CGF it is possible to have the CGF distributed to the SGSNs and/or GGSNs. 
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The CGF can reside in a separate network element (Charging Gateway) or be integrated in the GSNs. It can receive 
CDR fields from the GSNs in real time mode. It should have enough storage to enable it to transmit the collected 
charging data to the Billing System in file mode. 

The CGF may have to support several transmission protocols towards the BiUing System, depending on the Billing 
System(s) used. One of the main purposes of the CG (or even just a CGF) is to reduce the number of different interfaces 
between the billing system (BS) and the GGSNs and SGSNs sending charging data. If a new BS is introduced it must be 
interfaced to the CGF, i.e. the protocol stacks and configurations of the GSNs do not need not to be updated. The usage 
and load of mass memory media can be more evenly distributed. The portion of the CGF embedded into a single 
physical device is called the Charging Gateway entity. The CGF may be distributed to several physical Charging 
Gateways or GSNs, to facilitate redundancy. If that Charging Gateway entity that is the Primary Charging Gateway 
entity, does not respond to communication originating from the GSNs, the GSNs will try to send the CDR data to a 
Secondary Charging Gateway entity. Here each GSN will have several IP addresses (of different priority) for the 
Charging Gateway entities, thus avoiding downtime of the CGF. 



5 Charging Principles 

5.1 Requirements 

1) Every GPRS operator collects and processes their ovra charging information. 

2) GPRS charging shall support anonymous access to the GPRS bearer service. 

3) As much as is possible the GPRS charging functions should support open interfaces for possible use in future 
cellular digital packet based networks. 

4) It shall be possible to provide reverse charging as a subscription option. However, reverse charging may not be 
applicable to certain external data network protocols. 

5) Every PDP context shall be assigned a unique identity number for billing purposes, (i.e. the charging id). 

6) Data volumes on both the uplink and downlink direction shall be counted separately. The data volumes shall 
reflect the application data as precisely as possible as delivered by the user. 

7) The charging mechanisms shall provide the duration of the PDP context with date and time information. 

8) The GPRS operator may define a subset of the charging information specified by GPRS charging standards. This 
means that it shall be possible to configure the SGSN and GGSN for the CDR information generated. 

9) The SGSN and GGSN are not obliged to have non-volatile memory. 

This means that a GSN may loose its data when reset. The only permanent information that must be stored in a 
GSN is the configuration data (e.g. cell/RA definition in SGSN). 

5.2 Charging Information 

Charging information in the GPRS network is collected for each MS by the SGSNs and GGSNs which are serving that 
MS. The information that the operator uses to generate an invoice to the subscriber is operator-specific. Billing aspects, 
e.g., a regular fee for a fixed period, are outside the scope of this specification. 

The SGSN collects charging information for each MS related with the radio network usage, while the GGSN collects 
charging information for each MS related with the external data network usage. Both GSNs also collect charging 
information on usage of the GPRS network resources. 

PTP charging information is collected for the GPRS subscriber. 

As a minimum, the SGSN shall collect the following charging information: 

1) usage of the radio interface: the charging information shall describe the amount of data transmitted in MO and MT 
directions categorised with QoS and user protocols; 
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Charging based on user protocols (PDP context type) for sent/received data volume forms the basis for volume 
charging. All changes in QoS are recorded separately. This provides post-processing systems, if required, to sort out 
their charging relevance. 

2) usage of the packet data protocol addresses: the charging information shall describe how long the MS has used the 
packet data protocol addresses; 

Duration of PDP context is counted as the time interval from PDP Context activation to PDP Context Deactivation. 

3) usage of the general GPRS resources: the charging information shall describe the usage of other GPRS-related 
resources and the MSs GPRS network activity (e.g., mobility management). 

4) location of MS: HPLMN, VPLMN, plus optional higher-accuracy location information; 

As a minimum, the GGSN shall collect the following charging information: destination and source: the charging 
information shall describe the destination and source addresses with a level of accuracy as defined by the GPRS 

operator; 

5) Destination and source: the charging information shall describe the destination and source addresses with a level of 
accuracy as defined by the GPRS Operator. 

Distinction of the data traffic to different source and destination or subnetworks may be performed by using the APN ( 
Access Point Name). 

6) usage of the external data networks: the charging information shall describe the amount of data sent and received to 
and from the external data network. 

External networks can be identified by the APN (access point name). The volume counts can be charged by post- 
processing as configured. 

7) usage of the packet data protocol addresses: the charging information shall describe how long the MS has used the 
PDP addresses. 

8) location of MS: HPLMN, VPLMN, plus optional higher-accuracy location information. 
The highest accuracy location information available in GGSN is SGSN address. 

5.3 Charging Data Collection Principles 

Call data record generation and contents should be flexible and unnecessary redimdancy in data should be avoided. 

1. There are two main records types (one for the SGSN and one for the GGSN related to PDP contexts). Each PDP 
context generates its own record. A third record is provided for mobility management in the SGSN. The SGSN may 
also provide two SMS related records in case of short message delivery. 

2. Optional basic location information may be included in the PDP context records. 

3. Records shall only include relevant information, i.e. traffic activity since last record. 

The criteria for record generation is based on real time needs, information safety (backup) and some specific events, 
such as expiry of the partial record timer(s), transferred data volume hmit(s), inter SGSN routing area update. 

4. Change of tariff period (if used) should not cause new CDRs to be sent to avoid peaks in data transfer. Instead such 
events should close the existing volume counters and open new ones when appropriate traffic is detected. This can 
be done by having a new record in the same message. It is up to the operator how often the CDRs are transferred 
from a GSN. 

5. Both SSGN and GGSN nodes shall collect information from same chargeable sessions (PDP contexts). A unique 
reference (Charging ID and GGSN address) is needed to enable connection between information from several 
records produced from same PDP context. 
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5.4 



Generation of Charging ID 



The concept of serving connections is different in the GSM switching network to that for the GPRS network. Therefore 
different mechanisms are needed to supply the bilUng system centres with charging information. 

Circuit switched calls can be charged in one MSG (the anchor MSG) where all relevant data is available. That is 
guaranteed by routing all signalling information though the anchor MSG even if the traffic channel of a call is routed 

through another MSG due to handover. 

In a GPRS network the complete PDP context handling can be switched over from an old SGSN to a new SGSN due to 
routing area updates with the consequence that charging records will be generated in more than one SGSN. Furthermore 
different data has to be collected in the SGSNs and GGSNs. So for one PDP context, charging records are needed from 
both the SGSN and GGSN. 

The billing system shall be provided with all relevant information from the network to charge for that one activated PDP 
context. 

During the active PDP context all records which belong to this context could normally be identified by the TID. 
However 

- an MS can activate and deactivate PDP contexts in a very short time interval, and these PDP contexts can have 
the same TID (only parallel established PDP contexts have different TIDs); 

- different SGSNs can be involved in the same PDP context as described above; 

- the timing clocks of the GSN elements may not be fully synchronised. 

Therefore it is nearly impossible for a billing post-processing system to gather the records of one PDP context only by 
using the IMSI, NSAPI (TID) and time. 

This is solved by assigning a unique Charging ID number (C-ID) to all records generated for that one PDP context. 

The unique C-ID is generated in the GGSN when the PDP context is activated. A C-ID is generated for each activated 
context, so that each has a unique C-ID. The C-ID shall be transferred from the SGSN to another SGSN (following a 
routing area update). All PDP CDRs for each activated PDP context generated by each SGSNs and GGSNs shall 
therefore contain the same unique combination of the C-ID and GGSN address to permit subsequent Charging Gateway / 
BilUng System correlation of the generated CDRs. 

The GGSN address together with the C-ID are a unique identification over a long period of time in all GPRS networks. 



In GPRS the SMS transmission (MO or MT) can be done via SGSN. The SGSN shall provide an S-SMO-CDR 
when short message is mobile originated and an S-SMT-CDR when it is mobile terminated. In addition, also 
SMS-IWMSC (MO-SMS) and SMS-GMSC (MT-SMS) may provide SMS related CDRs as described in GSM 
12.05. 

No active PDP context is required when sending or receiving short messages. If the subscriber has an active PDP 
context, volimie counters of S-CDR are not updated due to short message delivery. 

The contents of S-SMO and S-SMT CDRs are presented in tables 8 and 9. 



S-CDRs and G-CDRs are generated by the SGSNs and GGSNs in the case of Anonymous Access, and separately 
identified in the CDRs. 

The external Anonymous Access server is charged by the Operator based on the APN. 



5.5 



Charging for SIVIS in GPRS 



5.6 



Charging for Anonymous Access 
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5.7 Charging Triggers - CDR Generation 

The S-CDR, M-CDR G-CDR, S-SMO-CDR, and S-SMT-CDR are generated by the SGSN and GGSN to collect 
charging information such that they may be subsequently transferred to the Charging Gateway Function. 

5.7.1 Triggers for S-CDR Charging Information Collection 

An S-CDR is used to collect charging information related to the packet data information for a GPRS mobile in the 
SGSN. 

An S-CDR shall be opened for each activated PDP context, and record details such as Record Type, Served IMSI, 
Sequence Number etc. Not all of the charging information to be collected is static, and other charging information is 
directly dependent on dynamic GPRS usage. 

The subsequent sections identify the conditions for adding information to, and closing, the CDR. 

5.7.1 .1 Triggers for S-CDR Charging Information Addition 

The "List of Traffic Volumes" attribute of the S-CDR consists of a set of containers which are added when specific 
trigger conditions are met, and identify the volume count separated for uplink and downhnk traffic on encountering that 
trigger condition. 



Table 1 : Triggers for S-CDR charging information addition 



Trigger Conditions 


Description/Behaviour 


QoS Change 


A change in the QoS shallresult in a "List of Traffic Data Volumes" 
container being added to the CDR. 


Tariff Time Change 


On reaching the Tariff Time Change a "List of Traffic Data Volumes " 
container shall be added to the CDR. 


CDR Closure 


A list of "List of Traffic Data Volumes" container shall be added to the 
S-CDR. 



5.7.1.2 Triggers for S-CDR Closure 

The S-CDR shall be closed on encountering some trigger conditions. The following table identifies which conditions are 
supported to permit closures of the S-CDR. 



Table 2: Triggers for S-CDR closure 



Closure Conditions 


Description/Behaviour 


End of PDP Context within 
the SGSN 


Deactivation of the PDP context in the SGSN shall result in the CDR 
being closed. The trigger condition covers:- 

- termination of PDP context, 

- SGSN change (inter-SGSN routing area update), 
any abnormal release. 


Partial Record Reason 


O&M reasons permit the closure of the CDR for internal reasons. The 
trigger condition covers :- 

- data volume Umit, 

- time (duration) limit, 

- maximum number of charging condition changes, 

- management intervention. 



In the event that the S-CDR is closed and the PDP context remains active, a further S-CDR shall be opened with an 
incremented Sequence Number. 
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5.7.2 Triggers for M-CDR Charging Information Collection 

An M-CDR is used to collect charging information related to the mobility management of a GPRS mobile in the SGSN. 

An M-CDR shall be opened for each GPRS mobile upon GPRS Attach, and record details such as Record Type, Served 
IMSI, Sequence Number etc. Not all of the charging information to be collected is static, and other charging information 
is directly dependent on GPRS mobiUty. 

The subsequent sections identify the conditions for adding information to, and closing, the CDR. 

5.7.2.1 Triggers for M-CDR Charging Information Addition 

The "Change of Location" attribute of the M-CDR consists of a set of containers which are added when specific trigger 
conditions are met, and identify the timestamped routing area on encountering that trigger condition. 



Table 3: Triggers for M-CDR Charging Information Addition 



Trigger Conditions 


Description/Behaviour 


Mobility Change 


A change in the Routing Area shall result in a "Change of Location" 
container being added to the M-CDR. 



5.7.2.2 Triggers for M-CDR Closure 

The M-CDR shall be closed on encountering some trigger conditions. The following table identifies which conditions 
are supported to permit closures of the M-CDR. 



Table 4: Triggers for M-CDR closure 



Closure Conditions 


Description/Beliaviour 


End of MM Context within 
SGSN 


Deactivation of the MM context in the SGSN shall result in the CDR 
being closed. The trigger condition covers:- 

- SGSN change (inter-SGSN routing area update), 

- GPRS detach, 

- any abnormal release. 


Partial Record Reason 


O&M reasons permit the closure of the CDR for internal reasons. The 
trigger condition covers:- 

- time (duration) limit, 

- maximiun number of mobility changes, and 

- Management intervention. 



In the event that the M-CDR is closed and the GPRS mobile is still known to the SGSN, a further M-CDR shall be 
opened with an incremented Sequence Number. 

5.7.3 Triggers for G-CDR Charging Information Collection 

A G-CDR is used to collect charging information related to the packet data information for a GPRS mobile in the 
GGSN. 

A G-CDR shall be opened for each activated PDP context, and record details such as Record Type, Served IMSI, 
Sequence Number etc. Not all of the charging information to be collected is static, and other charging information is 
directly dependent on dynamic GPRS usage. 
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The "List of Traffic Data Volumes" attribute of the G-CDR consists of a set of containers which are added following 
specific trigger conditions, and identify the volume count on encountering that trigger condition. The trigger conditions 
are as for the S-CDR (see previous section on "Triggers for S-CDR Charging Information Collection") with exception 
that the SGSN change does not need to close the CDR. 

In the event that the G-CDR is closed and the PDF context remains active, a further G-CDR is opened with an 
incremented Sequence Number. 

5.8 Example charging scenarios 

This clause contains a number of example scenarios illustrating the purpose and practical usage of the various types of 
records defined in the previous subclauses. These examples are by no means exhaustive. 

For the purpose of these examples the following assumptions have been made: 

- the CDR records are sent to a CGF; 

- the generation of all of the CDR record types has been enabled. 

The following conventions have been used for the figures contained within this subclause: 

1) Network connections and signalling transactions are illustrated by means of solid Unes and referenced by number 
e.g. (1). 

2) Operation & Maintenance actions, such as the transfer of call records, are represented by means of dotted Unes 
and referenced by letter e.g. (A). 

5.8.1 GPRS Mobile to PDN Context 

Figure 5 illustrates a simple outgoing GPRS context from a PLMN GPRS subscriber "A" to a mainframe "B" via a PDN 
(1). 

The respective PDP context is activated in the SGSN and GGSN and PDP PDUs are routed in MO and MT direction. 
The SGSN shall create a S-CDR and the GGSN shall create a G-CDR for subscriber "A". 

The records generated are subsequently transferred to the CGF (A). The CGF transfers the CDRs to the BS. 
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Figure 5: GPRS Mobile to PDN Context 

5.8.2 GPRS Mobile to Mobile Context 

Figure 6 illustrates a simple GPRS mobile to mobile context within the same HPLMN. 
The respective A-party related PDF context is activated in the SGSN-A and the GGSN (1). 

After the location of subscriber "B" is determined, the B party related PDF context is activated (2) in the SGSN-B and 
the GGSN and FDF FDUs are routed in MO and MT direction. The SGSN-A shall create an S-CDR and the GGSN 
shall create a G-CDR for subscriber A, the SGSN-B shall create a S-CDR and the GGSN shall create a G-CDR for 
subscriber "B". 

If subscriber "A" and subscriber "B" use the same GGSN, both G-CDRs are produced at that GGSN. 

If session leg (2) requires a FDF context activation the respective FDF records will contain a network initiated FDF 
context activation-flag. 



The records generated are subsequently transferred to the CGF (A). The CGF transfers the CDRs to the BS. 
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Figure 6: GPRS Mobile to Mobile Context 

5.8.3 PDN to GPRS Mobile Context 

Figure 7 illustrates a simple incoming GPRS context from a mainframe "A" to GPRS mobile subscriber "B" via a PDN 
(1). After the location of subscriber "B" is determined, the PDP context is activated (2). 

The GGSN receiving the PDUs shall generate a G-CDR whereas the SGSN currently serving subscriber "B" creates an 
S-CDR. These records contain a flag that the PDP context is activated due to network request. 

The records generated are subsequently transferred to the CGF (A). The CGF transfers the CDRs to the BS. 
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Figure 7: PDN to GPRS Mobile Context 
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5.8.4 GPRS Mobile to PDN Context while roaming, GGSN in HPLMN 

Figure 8 illustrates an outgoing GPRS context from a roaming GPRS mobile subscriber "A" to mainframe "B" via 
Boarder Gateway, inter PLMN backbone and GGSN of the HPLMN (1). 

The respective a-party related PDP context is activated in the SGSN and GGSN and PDUs are routed in MO and MT 
direction. The SGSN shall create an S-CDR (VPLMN) and a G-CDR is generated at the used GGSN (HPLMN) for 
subscriber "A". From the GGSN the packets are sent via the PDN to the mainframe "B". 

The records generated in the HPLMN and the VPLMN are subsequently transferred to the CGFs (A). The CGFs transfer 
the CDRs to the BS. (B) 

Later on the records created in the VPLMN are transferred from the BS to the BS of the HPLMN via TAP procedure 
(C). 




Figure 8: GPRS Mobile to PDN Context whilst roaming via BG 



6 Charging Data Collection 
6.1 Record contents 

The following tables describe the contents of each of the call and event records generated by the GSNs. Each table 
contains the name of the field, a key indicating whether or not the field is mandatory, and a description of the contents. 

The key field has the following meaning: 

M This field is mandatory and always present. Any exceptions to this rule are explicitly described. 
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C This field is only available under certain conditions. If available the field is present. 

The conditions under which the field is available are individually described. 

O This field is optional and configurable either via additional TMN management fiinctions or manufacturer specific 
means. For the avoidance of doubt, optional does not mean that the parameter is not supported by the network 
element. Equipment manufacturers shall be capable of providing all of these fields in order to claim conformance 
with this document. 

The mandatory, conditional, and optional designations are described at the GSN / CGF interface (see exceptions below) 
and may be available at the CGF / BS interface to meet the Billing System requirement. 

All the mandatory or conditional fields are not required in all CDRs at the GSN / CGF interface in the following cases: 

- Each information element is included at least in one record. This applies for situations where partial records are 
produced between the GSN and CGF, and the information has not changed, e.g. "GGSN Address Used". The 
following primary identifier fields are however needed in all records: Record Type, Served IMSI, and if the CDR 
is related to a PDP context (G-CDR and S-CDR), then also the Charging ID. 

- GSNs are configured to produce oidy part of the described information. This applies for situations where record 
types are not produced or some functional component is excluded from the records such as whole M-CDR or 
time based charging in G-CDR. 

In the case of a distributed CGF the following charging data records are not applicable at the GSN / CGF interface and 
proprietary solutions or variations to this standard are allowed. However, the described information content needs to be 
supported to be able to conform to the requirements towards the BS. 
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6.1 .1 GPRS charging data in SGSN (S-CDR) 

If the collection of SGSN data is enabled then the following GPRS SGSN data shall be available for each PDP context. 



Table 5: GPRS SGSN PDP context data 



Field 




Description 


Record Type 


M 


GPRS SGSN PDP context record. 


Network Initiated PDP 
Context 


C 


Present if this is a network initiated PDP context. 


Anonymous Access 
Indicator 


C 


Set to true to indicate anonymous access (and that the Served IMSI is not supplied) 


Served IMSI 


M 


IMSI of the served party (if Anonymous Access Indicator is FALSE or not 
supphed). 


Served IMEI 


C 


The IMEI of the ME, if available. 


SGSN Address 


M 


The IP address of the current SGSN. 


MS Network Capability 


O 


The mobile station Network Capability. 


Routing Area 


o 


Routing Area at the time of the record creation. 


Local Area Code 


o 


Location area code at the time of the record creation. 


Cell Identity 


o 


Cell id at the time of the record creation. 


1 nQTCTmo" Til 


IVl 


MIiM cfwyff^'vf irif^ntifif^T iicf^H fr\ iHf^ntiTA/ tnic MliP rr^ntf^vt m HiTTf^Tf^nt Tf^r*r\Tric r*Tf^5itf^ri 
r L/r i^uiiiCAi luciitiiiC'i uacu i\j luciitiij' una r l/i v^vjulcai in u-iiiciciii ici^vjiua L'lCo.icu 

by GSNs 




IVl 


1 lie i-T duuicoo vji iiiC' vJvJOi> L'UiiciiLij' UoCLi. 1 iic vJvJOi> dULiicaa la diwcij'a iiic aoiiic 
for an artivatpH PDP 


Afopss Point Namp 


M 


Xhp lof^ioal namp of thp ponnprtpH arrpss noint to tlip pxtpmal narlcpt Hata nptworlc 

X llv^ 1\_/ j^l^Lll llCilXX^ VJI. LllV^ WV-'llllV^^ LV^ Ll w w v.- l3 L/V/lllL VVJ vllw ^-/VvwlllCIX L/ Cl-^ I v w v vl-CivCI' 11^ v VV V/llV* 


PDP Tvne 


M 


PDP tvne e g X 25 IP PPP IHOSS OSP 

X X-^X I y L/Wj W>g> ^V..^^^ XX J X X X , XXXV.7kJkJ. V./kJX 


Served PDP Address 


M 


PDP address of the served IMSI e s an IPv4 IPv6 or X 121 

X X-^X C1VJ.VJ.1 Wi>L> V/1 LI 1^ l7w1 V W-Vl XJ.VXkJXj w.g. CU.1 XX V "5 XX V \J V/1 JT V. 1 1 . 


List of Traffic Data 
VnliiTTiPS 


M 


A list of changes in charging conditions for this PDP context, each time stamped. 
Charf^inf^ ponditions are iispd to patpp"orisp traffip vohimps siiph as npr OoS/tariff 

V^llLll fLLlliL. ^\_'llx_ll LIWIIlj til w LI > > V_l LW ^ LLL^ £uWl 1 V.^ LI LLl 11^ V VJI LLIXXV^lj , ljLL^II LLlj L/V/l \^VJ^/ LLLl 11 1 

period. Initial and subsequently changed QoS and corresponding data values are 
listed. Data volumes are in Octets above the SNDCP layer and are separated for 
uplink and downlink traffic. 


Record Opening Time 


M 


Time stamp when PDP context activation is created in this SGSN 
or record opening time on following partial records 


Duration 


M 


Duration of this record in the SGSN. 


SGSN Change 


C 


Present if this is first record after SGSN change. 


Cause for Record Closing 


M 


The reason for the release of record from this SGSN. 


Diagnostics 


O 


A more detailed reason for the release of the connection. 


Record Sequence Number 


C 


Partial record sequence number in this SGSN. Only present in case of partial 
records. 


Node ID 





Name of the recording entity 


Record Extensions 


o 


A set of network/ manufacturer specific extensions to the record. 


Local Record Sequence 
Number 


o 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 
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6.1 .2 GPRS charging data in GGSN (G-CDR) 

If the collection of GGSN data is enabled then the following GPRS GGSN data shall be available for each PDP context. 



Table 6: GPRS GGSN PDP context data 



Field 




Dp<irH ntl nn 


Record Type 


M 


GPRS GGSN PDP context record. 


Network initiated PDP 
context 


c 


Present if this is a network initiated PDP context. 


Anonymous Access 
Indicator 


c 


Set to true to indicate anonymous access (and that the Served IMSI is not supplied). 


Served IMSI 


M 


IMSl of the served party (if Anonymous Access Indicator is FALSE or not 
supplied). 


GGSN Address 


M 


The IP address of the GGSN used. 


Charging ID 


M 


PDP context identifier used to identify this PDP context in different records created 
by GSNs 


SGSN Address 


M 


List of SGSN addresses used during this record. 


A CCf^QQ Pr^lirf ^UQTTlf^ 


iVl 


Tnp lr\(Tir*cil ncunp r\T tnp rT\nnpr*fpri nrr'PCG nrxitrf tr\ trip PYtPTTiJil T\Qr*K'pt riJitQ ■nptw/r^Tlr 
i lie lyJ^iK^al ildiilC KjL LllC l^L/IIIICl^LCLl tH^l^Cio lJUlllL WJ tllC CAlCillCU UdL/A-Cl UcliCl IICIWUIA.. 


PDP Tvnp 


M 

IVl 


PDP tvnp p CT Y 9S TP PPP or THO'^'^-n'^P 




M 

±V1 


PDP aHHrpsis: p a an TPv4 TPvfi nr IC 191 


Ppmr\tp PT^P AHHrpcc 


n 


T let r\T PliP nHrifPCGPG r\T trip fpmntp nr^ct cw \ \ 1 ' M p ct nn TPi jA TP\/n cw )t 1 vl 

("Included if the PDP tvne is X 25~) 




c 


TnHiratPs wliptlipr sprvpH PDP aHHrp'is i'i Hvnamir tliat I'i allnratpH Hiirinp" PDP 
context activation. 


List of Traffic Data 
Volumes 


M 


A list of changes in charging conditions for this PDP context, each time stamped. 
Charging conditions are used to categorise traffic volumes, such as per tariff period. 
Initial and subsequently changed QoS and corresponding data values are listed. Data 
volumes are in octets above the GTP layer and are separated for uplink and 
downUnk traffic. 


Record Opening Time 


M 


Time stamp when this record was opened. 


Duration 


M 


Duration of this record in the GGSN . 


Cause for Record Closing 


M 


The reason for the release of record from this GGSN . 


Diagnostics 


O 


A more detailed reason for the release of the connection. 


Record Sequence Number 


c 


Partial record sequence number, only present in case of partial records. 


Node ID 





Name of the recording entity. 


Record Extensions 





A set of network/ manufacturer specific extensions to the record. 


Local Record Sequence 
Number 


o 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 
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6.1 .3 GPRS mobile station mobility management data in SGSN (M-CDR) 

If the collection of MS mobility management data is enabled then GPRS SGSN shall start collecting infonnation each 
time the mobile is attached to the SGSN. 



Table 7: GPRS SGSN mobile station mobility management data 



Field 




Description 


Record Type 


M 


GPRS SGSN mobility management record. 


Served IMSI 


M 


IMSI of the MS. 


Served IMEl 


C 


The IMEI of ihc ME. if available. 


SGSN Address 


M 


The IP address of the current SGSN. 


MS Network Capability 


O 


The mobile station network capabihty. 


Routing Area 


o 


Routing Area at the time of the record creation.. 


Local Area Code 





Location Area Code at the time of record creation. 


Cell Identity 





Cell id at the time of the record creation. 


Change of Location 


o 


A list of changes in Routing Area Identity, each time stamped. 


Record Opening Time 


M 


Timestamp when this record was opened. 


Duration 


O 


Duration of this record. 


SGSN Change 


C 


Present if this is first record after SGSN change. 


Cause for Record Closing 


M 


The reason for the release of the record in this SGSN. 


Diagnostics 


O 


A more detailed reason for the release of the connection. 


Record Sequence Number 


C 


Partial record sequence number in this SGSN, only present in case of partial 
records. 


Node ID 


O 


Name of the recording entity. 


Record Extensions 


o 


A set of network/ manufacturer specific extensions to the record. 


Local Record Sequence 
Number 


o 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 



6.1 .4 GPRS MO SMS data in SGSN (S-SMO-CDR) 



If enabled, an S-SMO-CDR SGSN Mobile originated SMS record shall be produced for each short message sent 
by a mobile subscriber via SGSN. 



Table 8: SGSN Mobile originated SlUIS record 



Field 




Description 


Record Type 


M 


SGSN Mobile Originated SMS. 


Served IMSI 


M 


The IMSI of the subscriber. 


Served IMEI 


O 


The IMEI of the ME, if available. 


Served MSISDN 


o 


The primary MSISDN of the subscriber. 


MS Network Capability 


M 


The mobile station network capability. 


Service Centre 


M 


The address (E.164) of the SMS-service centre. 


Recording Entity 


M 


The E. 164 number of the SGSN. 


Location Area Code 


O 


The Location Area Code from which the message originated. 


Routing Area Code 





The Routing Area Code from which the message originated. 


Cell Identity 


o 


The Cell Identity from which the message originated. 


Event Time Stamp 


M 


The time at which the message was received by the SGSN from the 

subscriber. 


Message Reference 


M 


A reference, provided by the MS uniquely identifying this message. 


SMS Result 


C 


The result of the attempted delivery if vmsuccessfiil. 


Record Extensions 


o 


A set of network/ manufacturer specific extensions to the record. 


Node ID 


o 


Name of the recording entity. 


Local Record 
Sequence Number 


o 


Consecutive record number created by this node. The number is allocated 
sequentially including all CDR types. 
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6.1 .5 GPRS MT SMS data in SGSN (S-SMT-CDR) 

If enabled, an SGSN Mobile terminated SMS record shall be produced for each short message received by a 
mobile subscriber via SGSN. 



Table 9: SGSN Mobile terminated SMS record 



Field 




Description 


Record Type 


M 


SGSN Mobile terminated SMS. 


Served IMSI 


M 


The IMSl of the subscriber. 


Served IMEl 





The IMEl of the ME. if avaikible. 


Served MSISDN 


O 


The primary MSISDN of the subscriber. 


MS Network Capability 


M 


The mobile station network capabihty 


Service Centre 


M 


The address (E. 164) of the SMS-service centre. 


Recording Entity 


M 


The E. 164 number of the SGSN. 


Location Area Code 


O 


The Location Area Code to which the message was delivered. 


Routing Area Code 


O 


The Routing Area Code to which the message was delivered. 


Cell Identity 


o 


The Cell Identity to which the message was delivered. 


Event Time Stamp 


M 


Delivery time stamp, time at which message was sent to the MS by the 

SGSN. 


SMS Result 


C 


The result of the attempted deUvery if unsuccessful. 


Record Extensions 





A set of network/ manufacturer specific extensions to the record. 


Node ID 


o 


Name of the recording entity. 


Local Record 
Sequence Number 


o 


Consecutive record niunber created by this node. The number is allocated 
sequentially including all CDR types. 



6.1 .6 Description of Record Fields 

This subclause contains a brief description of each field of the CDRs described in the previous subclause. 

6.1 .6.1 Access Point Name 

This field contains the logical Access Point Name used to determine the actual connected access point. APN comprises 
of mandatory network identifier and optional operator identifier. APN can also be a wildcard, in which case SGSN 
selects the access point address. See GSM 09.60 [22] and GSM 03.60 [8] for more information about APN format and 
access point decision rules. 

6.1 .6.2 Cause for Record Closing 

This field contains a reason for the release of the CDR including the following: 

- normal release: PDP context release or GPRS detach; 

- partial record generation: data volume hmit, time (duration) limit, SGSN change of maximum number of changes 
in charging conditions; 

abnormal termination (PDP or MM context); 

management intervention (request due to O&M reasons). 

A more detailed reason may be found in the diagnostics field. 



ETSI 



(GSM 12.15 version 7.2.1 Release 1998) 



28 



ETSI TS 101 393 V7.2.1 (1999-07) 



6.1.6.3 Charging ID 

This field is a charging identifier which can be used together with GGSN address to identify all records produced in 
SGSN(s) and GGSN involved in a single PDP context. Charging ID is generated by GGSN at PDP context activation 
and transferred to context requesting SGSN. At inter-SGSN routing area update charging ID is transferred to the new 
SGSN as part of each active PDP context. 

Different GGSNs allocate the charging ID independentiy of each other and may allocate the same numbers. The CGF 
and/or BS may check the uniqueness of each charging ID together with the GGSN address and optionally (if still 
unambiguous) with the record opening time stamp. 

6.1.6.4 Diagnostics 

This field includes a more detailed technical reason for the release of the connection and may contain one of the 
following: 

- a MAP error from GSM 09.02 [17]; 

- a Cause fi-om GSM 04.08 [16]; 

The diagnostics may also be extended to include manufacturer and network specific information. 

6.1.6.5 Duration 

This field contains the relevant duration in seconds for PDP contexts (S-CDR, G-CDR, and attachment (M-CDR)). For 
partial records this is the duration of the individual partial record and not the cumulative duration. 

It should be noted that the internal time measurements may be expressed in terms of tenths of seconds or even 
milliseconds and, as a result, the calculation of the duration may result in the roimding or truncation of the measured 
duration to a whole number of seconds. 

Whether or not rounding or truncation is to be used is considered to be outside the scope of this Specification subject to 
the following restrictions: 

1) A duration of zero seconds shall be accepted providing that the transferred data volume is greater than zero. 

2) The same method of truncation/rounding shall be appUed to both single and partial records. 

6.1 .6.6 Dynamic Address Flag 

This field indicates that PDP address has been dynamically allocated for that particular PDP context. Field is missing if 
address is static i.e. part of PDP context subscription. Dynamic address allocation might be relevant for charging e.g. the 
duration of PDP context as one resource offered and possible owned by network operator. 

6.1 .6.7 Event Time Stamps 

These fields contain the event time stamps relevant for each of the individual record types. 
All time-stamps include a minimum of date, hour, minute, and second. 

6.1 .6.8 GGSN Address/GGSN Address Used 

These fields contain one IP address of GGSN. 

The S-CDR fields contain a single address of current GGSN used. 

The G-CDR fields contain an address of current GGSN. 

6. 1 .6.9 List of Traffic Data Volumes 

This list includes one or more containers, which each include the following fields: 
Data Volume UpUnk, Data Volume Downlink, Change Condition and Time Stamp. 
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Data Volume includes the number of octets transmitted during the use of packet data services. 

Change condition defines the reason for closing the container (see 5.7.1 and 5.7.3), such as tariff time change, QoS 
change or closing the CDR. Change time is a time stamp which defines the moment when the new volume counts are 
started or CDR is closed. All the active PDP contexts do not need to have exactly the same time stamp e.g. due to same 
tariff time change (variance of the time stamps is implementation and traffic load dependent and is out of the scope of 
standardisation). 

First container includes following optional fields: QoS Requested (not in G-CDR) and QoS Negotiated. In following 
containers QoS Negotiated is present if previous change condition is QoS change. 

Following is an example of a hst, which has three containers (sets of volume counts) caused by one QoS change and one 
tariff time change. 



Table 10: Example list of traffic data volumes 



QoS Requested = QoS1 






QoS Negotiated = QoS1 


QoS Negotiated = QoS2 




Data Volume Uplink = 1 


Data Volume Uplink = 5 


Data Volume Uplink = 3 


Data Volume Downlink = 2 


Data Volume Downlink = 6 


Data Volume Downlink = 4 


Change Condition = QoS change 


Change Condition = Tariff change 


Change Condition = Record closed 


Time Stamp = TIME1 


Time Stamp = TIME2 


Time Stamp = TIMES 



First container includes initial QoS values and corresponding volume counts. Second container includes new QoS values 
and corresponding volume counts before tariff time change. Last container includes volume counts after the tariff time 
change. Following total volume counts can be itemised (tariff 1 is used before and tariffZ after the tariff time change): 



Container 



QoS1+Tariff1 


uplink = 1 , downlink = 2 


1 


QoS2+Tariff1 


uplink = 5, downlink = 6 


2 


QoS2+Tariff2 


uplink = 3, downlink = 4 


3 


QoS1 


uplink = 1 , downlink = 2 


1 


QoS2 


uplink = 8, downlink = 10 


2+3 


Tariffi 


uplink = 6, downlink = 8 


1+2 


Tariff2 


uplink = 3, downlink = 4 


1 



The amount of data counted in the GGSN shall be the data volume sent over the OTP layer. Therefore the data 
countedalready includes the rP/X.25 PDP bearer protocols. 

The data volume counted in the SGSN covers the amount of data transferred in the SNDCP PDUs. Therefore the data 
counted already includes the IP/X.25 PDP bearer protocols. 

In order to avoid that downstream packets transmitted from the old SGSN to the new SGSN at inter SGSN RA update 
induce the increase of the PDP CDR downstream volume counters in both SGSN the following rule is followed : 

for PDP contexts using LLC in unacknowledged mode : an SGSN shall update the PDP CDR when the packet 
has been sent by the SGSN towards the MS 

for PDP contexts using LLC in acknowledged mode : an SGSN shall only update the PDP CDR at the reception 
of the acknowledgement of the correct reception of a downstream packet by the MS. This implies that for 
downstream packets under transmission at inter SGSN RA update a packet sent by the old SGSN actually 
received by the MS and acknowledged by the MS towards the new SGSN through the RA update complete 
message induces the update of the PDP CDR record by the new SGSN. 

Data volumes retransmitted (by RLC or LLC) due to poor radio link conditions shall not be counted. 

6.1.6.10 Local Record Sequence Number 

This field includes a unique record number created by this node. The number is allocated sequentially including all CDR 
types. The number is unique within one node, which is identified either by field Node ID or by record dependent node 
address (SGSN address, GGSN address. Recording Entity) 
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The field can be used e.g. to identify missing records in post processing system. 

6.1 .6.1 1 Message reference 

This field contains a unique message reference number allocated by the mobile station when transmitting a short 
message to the service centre. This field corresponds to the TP-Message-Reference element of the SMS_SUBMIT PDU 
defined in GSM 03.40. 

6.1.6.12 MS Network Capability 

This MS Network Capabihty field contains the MS network capability value of the MS network capability information 
element ofthe served MS on PDF context activation or on GPRS attachment as defined in GSM 04.08 [16]. 

6.1.6.13 Network Initiated PDP Context 

This field indicates that PDP context is network initiated. The field is missing in case of mobile activated PDP context. 



This field contains an optional operator configurable identifier string for the node which generated the CDR. 

6.1.6.15 PDP Type 

This field defines the PDP type, e.g. X.25, IP, PPP, or IHOSS:OSP (see GSM 09.60 for exact format). 

6. 1 .6. 1 6 QoS Requested/QoS Negotiated 

Quality of Service Requested contains the QoS wanted by MS at PDP context activation. QoS Negotiated indicates the 
apphed QoS accepted by the network. 

The QoS profile consists of 5 attributes: reUabiUty, delay, precedence, peak throughput and mean throughput. See GSM 
03.60 [8] for more details. 

6.1.6.17 Record Extensions 

The field enables network operators and/or manufacturers to add their own extensions to the standard record definitions. 
This field contains a set of "management extensions" as defined in CCITT X.721 [5]. 

6.1 .6.1 8 Record Opening Time 

This field contains the time stamp when the record is opened (see GSM 12.05 for exact format). 

Record opening reason does not have a separate field. For G-CDR and M-CDR it can be derived from the field 
"Sequence number" i.e. missing field or value one means activation of PDP context and GPRS attachment. For S-CDR 
also field "SGSN change" need to be taken into account. 

6.1.6.19 Record Sequence Number 

This field contains a running sequence number employed to link the partial records generated in the SGSN/GGSN for a 
particular PDP context (characterised with same the Charging ID and GGSN address pair). In the S-CDR the sequence 
number is always started from one after inter-SGSN routing area update, see field "SGSN change". The Record 
Sequence Number is missing if the record is the only one produced in the SGSN/GGSN for the PDP context (e.g. inter- 
SGSN routing area update can result to two S-CDRs without sequence number and field "SGSN update" present in the 
second record). 



6.1.6.14 



Node ID 



6.1.6.20 



Record Type 



The field identifies the type ofthe record e.g. S-CDR, G-CDR, M-CDR, S-SMO-CDR and S-SMT-CDR. 
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6.1.6.21 Recording Entity Number 

This field contains the ITU-T E.164 number assigned to the entity that produced the record. For further details see GSM 
03.03. 

6. 1 .6.22 Remote PDP Address 

Remote PDP address may be used if PDP type is X.25. This parameter is not used if the PDP type is IP, PPP, or 
IHOSS:OSP. Itemised volume bilUng is available per Access Point Name. This field contains a Ust of connected remote 
PDP addresses. 

6.1 .6.23 Routing Area Code/Cell Identity/Change of location 

The location information contains a combination of the Routing Area Code (RAC) and optionally Cell Identity (CI) of 
the routing area and cell in which the served party is currently located. Any change of location (i.e. Routing Area 
change) may be recorded in the change of location field including the time at which the change took place. 

The change of location field is optional and not required if partial records are generated when the location changes. 

The RAC and (optionally) CI are coded according to GSM 04.08 [16]. 

6.1.6.24 Served IM El 

This field contains the international mobile equipment identity (IMEI) of the equipment served. The term "served" 
equipment is used to describe the ME involved in the transaction recorded e.g. the called ME in the case of a network 
initiated PDP context. 

The structure of the IMEI is defined in GSM 03.03 [14]. 

6.1.6.25 Served I MS I 

This fields contains the international mobile subscriber identity (IMSI) of the served party. The term "served" party is 
used to describe the mobile subscriber involved in the transaction recorded e.g. the calling subscriber in case of a mobile 
initiated PDP context . 

The structure of the IMSI is defined in GSM 03.03 [14]. 

6.1.6.26 Served MSISDN 

This fields contains the mobile station ISDN number (MSISDN) of the served party. The term "served" party is 
used to describe the mobile subscriber involved in the transaction recorded e.g. the called subscriber in case of an 
MTC record. In case of multi-numbering the MSISDN stored in a MOC record will be the primary MSISDN of 
the calling party. 

The structure of the MSISDN is defined in GSM 03.03. 

6. 1 .6.27 Served PDP Address 

This field contains the PDP address of the served IMSI. This is a network layer address e.g. of type IP version 4, IP 
version 6 or X.121. The address for each PDP type is allocated either temporarily or permanently, see field "Dynamic 
Address Flag". 

6. 1 .6.28 Service Centre Address 

This field contains a CCITT E.164 number identifying a particular service centre e.g. short message service centre (see 
GSM 03.40). 

6.1.6.29 SGSN Address 

These fields contain one or several IP addresses of SGSN. 
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The S-CDR fields contain single address of current SGSN and GGSN used. 

The G-CDR fields contains the address of the current GGSN and a hst of SGSNs, which have been connected during the 
record (SGSN change due to inter SGSN Routing Area update). 

The M-CDR only contains the address of the current SGSN. The M-CDR does not identify any information related to 
active PDF context(s) and thus does not know connected (used) GGSN(s). 

6.1.6.30 SGSN Change 

This field is present only in the S-CDR to indicate that this is the first record after an inter-SGSN routing area update. 

6.1 .6.31 Short Message Service Result 

This field contains the result of an attempt to deliver a short message either to a service centre or to a mobile 
subscriber (see GSM 09.02). Note that this field is only provided if the attempted dehvery was unsuccessful 



7 Charging Protocols 

The GTP' charging protocol is optional. GPRS nodes generate CDRs. These CDRs are to be collected by the CGF. The 
protocol GTP' has been designed to provide this CDR collection. 

The CGF-BS interface is also described in this chapter. 

7.1 GPRS CDR Collection by GTP' Protocol 

The GTP' protocol has been designed to deUver GPRS CDR's to the CGF(s) from those network elements or functional 
entities generating charging records. The GTP' protocol is required when the CGF resides in alternate nodes to those 
CDR generating nodes (e.g the SGSN and GGSN). The GTP' protocol designed for GPRS charging data collection has 
been derived from the GTP protocol (defined in GSM 09.60) which is used for packet data timneUing in the GPRS 
backbone network. 

GTP' is based on GTP with enhancements and additional message types. GTP' operates on the Ga interface. GTP' 
however does not imply the use of the GPRS backbone network, and may be implemented on alternate bearers. 

The GTP' contains the following fimctions: 

- CDR transfer mechanism between GPRS nodes generating CDRs and the Charging Gateway FunctionaUty. 

- Redirection of CDR transfer to another CGF. 

- Ability to detect conununication failures between the CDR handling GPRS network elements by echo messaging. 

- Ability of a CDR handling node to advertise the peer CDR handling GPRS network elements about its CDR 
transfer capability (e.g. after a period of service downtime). 

- Ability to prevent duplicate CDRs that might arise during redundancy operations. If so configured, the CDR 
duplication prevention function may also be carried out by marking potentially duplicated CDR packets and 
delegating the final duphcate deletion task to CGF or Billing System (instead of handling the possible duphcates 
solely by GTP' messaging). 

- The aim of the duplication prevention support of GTP' is to reduce the number of duplicated CDRs send towards 
the BS and to support the BS in keeping the efforts for duplictate CDR checking as small as possible. 

7.1 .1 SGSN - CGF communication 

SGSN - CGF : GTP' over UDP/TCP and IP 
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Figure 9: Protocol layers between the SGSN and the CGF 

7.1 .2 GGSN - CGF communication 

GGSN - CGF : GTP' over UDP/TCP and IP: 

G-CDRs > G-CDRs 
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Figure 10: Protocol layers between the GGSN and the CGF 



7.1.3 CGF - CGF communication 

CGF - CGF : GTP' over UDP/TCP and IP: 
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Figure 11: Protocol layers between CGFs 



7.1.4 Port usage 

GPRS charging may be facilitated by sending the CDRs from the GSNs to the CGF over theGa interface. The Path 
Protocol may be UDP [compliant with STD0006] or TCP [compliant with STD 0007]. 

7.1 .4.1 UDP as the Path Protocol 

Ports for signalling the request messages: 

The UDP Destination Port may be the server port number 3386 which has been reserved for GTP. Alternatively 
another port can be used which has been configured by O&M. 

- The UDP Source Port is a locally allocated port number at the sending GSN. 
Ports for signalling the response messages: 

- The UDP Destination Port value shall be the value of the Source Port of the corresponding request message. 

- The UDP Source Port shall be the value from the Destination Port of the corresponding request message. 



7.1.4.2 



TCP as Path Protocol 



The TCP Destination Port may be the server port number 3386 which has been reserved for G-PDUs. Alternatively 
another port may be used as configured by O&M. Extra implementation specific destination ports are possible but all 
CGFs shall support the server port number. 

The TCP Source Port is a random port, locally assigned at the sending GSN. 

7.1 .4.3 Network layer and lower layers 



Beneath the Path Protocol there is the network IP layer which shall be the Internet Protocol (IP) compliant with STD 
0005. Beneath the network IP layer are the L2 and LI layers, which are not specified in this document. 

7.1 .5 Charging related requirements for GPRS nodes 

Each GPRS node (SGSN, GGSN, CGF, and in future the PTM-SC) supporting GTP' shall be capable of handhng or 
responding with a "ServiceA^ersion not supported" message if that node is configured to be addressed by another GPRS 
node. 
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When a new PDP context is activated or after an inter SGSN handover the GGSN will inform the related SGSN which 
CGF it should send its CDRs to. All other non PDP context related CDRs are sent to the current default CGF for that 
CDR generating node. Each CDR generating node will have an O&M configurable CGF address list to which it can send 
its CDRs. The list will be organized in CGF address priority order. If the Primary CGF is e.g. out of service, then the 
CDR generating node shall send the CDRs to the Secondary CGF and so on. 

Each GPRS CDR generating node will only send the records to the CGF(s) of the same GPRS PLMN, not to CGF(s) 
located in other PLMNs. 

Each CGF in the GPRS PLMN shall know of all other CGFs network addresses. This is achieved by O&M 
configuration faciUties that will enable each CGF to have a configurable Ust of peer CGF addresses. 



7.2 The GTP' charging protocol 

This section describes the necessary enhancements and additional message types to the basic GTP protocol, described in 
GSM 09.60, for GPRS charging data collection. 

7.2.1 Usage of GTP Header in cliarging 

The GTP header defined in GSM 09.60 is reused. In GPRS charging, only the signalling plane of GTP is used. 
Bit 5 of octet 1 of the GTP header is the Protocol Type flag and is '0' if the message is GTP'. 
The Version bits indicate the GTP' protocol version when the Protocol Type flag is '0'. 
LFN flag (LLC Frame Number flag) is not used in GTP', and it is '0' in the GTP' header. 

LLC Frame Number in GTP' header is always set to 255 by the sender and shall be ignored by the receiver. 

TID is the tunnel identifier that points out MM and PDP contexts. In GPRS charging, it is not used, and it is always 0. 

Bits 

87654321 

^••-••-••-••-••-••-••-••-••-••-••-••-y -t ...........................J............. 

i i i i 

Version \ PT \ Spare '111' ! LFN j 

Ms.ssaa®..!)^® ' 

.l:d?D9ttl ' 

Sequence number i 



Octets 



1 
2 

3-4 



Figure 12: Start of the GTP/GTP' header 



7.2.2 Information elements 

Signalling messages may contain several information elements. The TLV (Type, Length, Value) or TV (Type, Value) 
encoding formats shall be used for the GTP' information elements. The signalling messages for GTP' shall have the 
information elements sorted with the Type fields in ascending order. The Length field shall contain the information 
element length excluding the Type and Length fields. 

Within the Type field the most significant bit will be set to when the TV format is used and set to 1 when the TLV 
format is used. 
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Figure 12: Type field for TV and TLV format 



7.3 GTP' Message Types 
7.3.1 List of all GTP' message types 

GTP defines a set of signalling messages between two associated GSN nodes. The signalling messages defined are 
shown in table 1 1 . The enhancements introduced by GTP' are printed in this table in boldface. The messages modified 
due to the GPRS charging requirements are printed in italics. 

Of the new signalhng message types, Node Ahve Request, Node Alive Response, Redirection Request and Redirection 
Response belong to the Path Management messages. The Data Record Transfer Request and Data Record Transfer 
Response form a new GTP signaUing message type group: Record Transmission messages. 

The reserved fields in the signalling messages shall be tilled with ones, and are intended for future use. 

GTP' shall reuse the GTP Cause values. The GTP' message type numbers needed for charging have been derived from 
the imallocated message type number space specified in GSM 09.60. 

The number ranges allocated for GTP' are as follows: 

For Information Elements : 117-127 (TV type fields) and 239-254 (for TLV type fields). 

TLV Information Element types introduced in this specification: 

254 Address of Recommended Node 

253 Requests Responded 

252 Data Record Packet 

251 Charging Gateway Address (this IE is also used in GSM 09.60) 

250 Sequence Numbers of Cancelled Packets 

249 Sequence Numbers of Released Packets 

TV Information Element types introduced in this specification: 
127 Charging ID 

For Cause Codes : Cause values used in requests: 49 to 63, Cause values used in responses indicating acceptance: 177 
to 191, Cause values used in responses indicating rejection: 241 to 255. 

Charging related Cause values introduced for this specification: 

In requests: 

63 This node is about to go down 
62 Another node is about to go down 
61 The receive buffers are becoming full 
60 The transmit buffers are becoming full 
59 System failure 

In responses indicating acceptance: 
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In responses indicating rejection: 
255 Request not fulfilled 

254 Sequence numbers of released/cancelled packets IE incorrect 

253 Request already fulfilled 

252 Request related to possibly duplicated packets already fulfilled 

The charging related message types are listed in the following signalling message table. If the Signalling Messages table 
defined in GSM 09.60 differs other than the boldfaced message types in table 11, then the defined signalling table in 
GSM 09.60 shall be considered as the latest version of the two tables. 



Table 11 : Signalling messages 



Message 
Type value 
(Decimal) 


Signalling message 


1 


Echo Request 


2 


Echo Response 


3 


Version Not Supported 


4 


Node Alive Request 


5 


Node Alive Response 


6 


Redirection Request 


7 


Redirection Response 






16 


Create PDP Context Request 


17 


Create PDP Context Response 


18 


Update PDP Context Request 


19 


Update PDP Context Response 


20 


Delete PDP Context Request 


21 


Delete PDP Context Response 


22 


Create AA PDP Context Request 


23 


Create AA PDP Context Response 


24 


Delete AA PDP Context Request 


25 


Delete AA PDP Context Response 


26 


Error Indication 


27 


PDU Notification Request 


28 


PDU Notification Response 


29 


PDU Notification Reject Request 


30 


PDU Notification Reject Response 






32 


Send Routing Information for GPRS Request 


33 


Send Routing Information for GPRS Response 


34 


Failure Report Request 


35 


Failure Report Response 


36 


Note MS GPRS Present Request 


37 


Note MS GPRS Present Response 






48 


Identification Request 


49 


Identification Response 


50 


SGSN Context Request 


51 


SGSN Context Response 


52 


SGSN Context Acknowledge 






240 


Data Record Transfer Request 


241 


Data Record Transfer Response 






255 


T-PDU 






Others 


reserved for future use 
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7.3.2 Reused GTP message types 

The existing Echo Request and Echo Response messages defined in GSM 09.60 are also used in GPRS charging. They 

may be used by the CDR generating nodes SGSN or GGSN, or by the CGF for checking if another GSN or CGF is 
ahve. If this specification and GSM 09.60 differ in their description then the GSM 09.60 is to be taken as the latest 
specification status of the related Information elements. If the path protocol is TCP, Echo Request and Echo Response 
messages are not required. 

The Version Not Supported message in the GTP' resembles much the corresponding GTP message. It indicates the 
latest GTP' version that the GTP' entity can support. If a receiving node receives a GTP' signalhng mesage of an 
unsupported version, that node shall return a GTP' Version Not Supported message indicating in the Version field of the 
GTP' header the latest GTP' version that that node supports. The received payload data of the GTP' packet shall then be 
discarded. 

The Version bits in the GTP' header have currently the following possible values: 

GTP' version (binary '000') is the GSM 12.15 v7.0.0 (October 1998) level, with the following Message Type values: 
3 = Version Not Supported , 4 = Node Ahve Request, 5 = Node Alive Response, 6 = Redirection Request, 7 = 
Redirection Response. In Chapter 7.3.4.6 the Requests Responded information element has Length field in place of the 
Number of Requests Responded field, to make that TLV IE to be handled like normal TLV lEs. 

GTP' version 1 (binary '001') is the same as version 0, but with the duplicate CDR prevention mechanism, introduced 
in this specification version. 

7.3.3 GTP message type modifications implied by OTP' 

The GPRS charging related features in GTP are in the Create PDP Context Response: the Charging ID information 
element and the Charging Gateway Address IE, in the Update PDP Context Response the Charging Gateway Address 
IE, in the Create AA PDP Context Response: the Charging ID IE and the Charging Gateway Address IE. Refer to the 
GSM 09.60 for the details. 

The general principle is that the CDRs are always sent to a CGF residing in the same network as the CDR generating 
node. In the case of roaming it is conceivable that some CDRs relating to the same PDP context will be sent to different 
networks' CGFs. The cost balancing of the roaming traffic is to be agreed between the GPRS Operators. 

7.3.4 GTP' message types 
7.3.4.1 Node Alive Request 

The Node Alive Request message may be used to inform that a node in the network has started its service (e.g. after a 
service break due to software or hardware maintenance or data service interruption after an error condition). A node may 
send a different Node Address than its own in the information element, e.g. informing the "next node in the chain" that 
the "previous node in the chain" (which is located on the other side of the sender of this message) is now ready for 
service. This message type is optional if the Path Protocol is TCP. 

The Node Alive Request message allows a quicker reconnect capability than the Echo Request message based polling 
can provide, and its usage will have a reduced load effect on the network, particularly when the number of network 
nodes using GTP' is high. It may also be used to inform when a new network node has become available for service. If 
the Echo Request message is also used then the usage of the Node Ahve Request message allows the interval of Echo 
Requests to be longer than would be otherwise required, thus reducing network loading with many Echo Requests. 



Table 12: Information elements in a Node Alive Request 



Information element 


Presence requirement 


Node Address 


Mandatory 


Private Extension 


Optional 



The Node Address format is the same as for the Charging Gateway Address format described earlier in this 
specification. 

The optional Private Extension information element contains vendor or operator specific information. 
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7.3.4.2 Node Alive Response 

The Node Alive Response message shall be sent as a response to a received Node Ahve Request. 



Table 13: Information elements in a Node Alive Response 



Information element 


Presence requirement 


Private Extension 


Optional 



The optional Private Extension information element contains vendor or operator specific information. 

7.3.4.3 Redirection Request 

There are two kinds of usage for the Redirection Request message. One is to advise that received CDR traffic is to be 
redirected to another CGF due to that CGF node is about to stop service (due to an outage for maintenance or an error 
condition). The second purpose is to inform a CDR generating node (e.g. SGSN) that is currently sending data to this 
node (e.g. CGF), that the next node in the chain (e.g. a mediator device or BUhng Computer) has lost cormection to this 
node (e.g. CGF). 



An Address of Recommended Node may be given if for example a CGF maintenance outage is handled by first 
introducing another CGF ready to take incoming CDRs. In this way the network performance can be maintained. The 
Address of Recommended Node shall only describe an intra-PLMN node containing a CGF, and not to a node in any 
other PLMN. 



Table 14: Information elements in a Redirection Request 



Information element 


Presence requirement 


Cause 


Mandatory 


Address of Recommended 
Node 


Optional 


Private Extension 


Optional 



Possible Cause values are: 

- "This node is about to go down" 

- "Another node is about to go down" 

- "System failure" 

- "Receive buffers becoming full" 

- "Send buffers becoming full" 

The Address of Recommended Node information element defines the address that the node is identified by in the GPRS 
network. 

Bits 

Octets 8 7 6 5 4 3 2 1 

Type = 254 (Decimal) 
Length = 4 (Decimal) 
IPv4 Address 



Figure 13: Address of Recommended Node information element 

The optional Private Extension contains vendor or operator specific information. 

7.3.4.4 Redirection Response 

The message shall be sent as a response of a received Redirection Request. 



1 

2-3 
4-7 
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Table 15: Information elements in a Redirection Response 



Information element 


Presence requirement 


Cause 


IVlandatory 


Private Extension 


Optional 



Possible Cause values are: 

- "Request Accepted" 
"No resources available" 

- "Service not supported" 

- "System failure" 
"Mandatory IE incorrect" 
"Mandatory IE missing" 

- "Optional IE incorrect" 
"Invalid message format" 
"Version not supported" 

The optional Private Extension contains vendor or operator specific information. 
7.3.4.5 Data Record Transfer Request 

This message is used in GPRS charging to transmit the CDR information. The CDR information is placed in the Data 
Record information element. 

7.3.4.5.1 Genaral logic 

This chapter is intended to be read together with chapter 7.3.4.7 "Examples of GTP' messaging cases". The normal 
communication would be GSN sending Data Record Packets to a CGF, which answers with "Request Accepted" 
responses. Under normal condition the CDR transmission uses a Request-Response messaging sequence in the GSN to 
CGF GTP' protocol communication. 

Sometimes a non-PDP context related CDR (e.g. M-CDRs) is transmitted, and thus the GGSN does not pass the CGF 
address information to the SGSN. The SGSN will in this case direct the CDRs to the current default CGF for the SGSN. 
This is the configured Primary CGF address, or if that CGF is out of service, then the secondary CGF address etc. 

Summary of the CGF redundancy mechanism that prevents duplicated CDR packets to enter the BS: 

The general logic of the duplicate CDR packet prevention in CGF redundancy cases is shown in the following diagram, 
where the message numbers are numbered in the order of time sequence. Alternative messages are indicated by an index 
character ('a' or 'b') that follows the arrow sequence number.. 

The main mechanism of the messaging in CGF redundancy cases (when a GSN-CGF link is down or a CGF is not 
working) is based on (I) tirst trying to send a CDR packet to CGF I. Then if no successful response is received (2) 
because the request does not reach CGFl even when retried (or the responses from CGFl to GSN are lost after CGFl 
either stored it securely or sent it towards postprocessing (2b)), the unacknowledged CDR packets are redirected to 
CGF2. The GSN may first test the GSN-CGF2 link by a Echo Request message, that the CGF2 would respond by Echo 
Response. The CDR packets not successfiiUy received by the primary CGF (=CGF1) are sent to another CGF2 (3), 
marked as potential duplicates, and CGF2 responds the request(s) (4). Those CDRs will wait there for further commands 
from GSN. When the GSN detects (5) and (6) that CGFl is again able to communicate with it by receiving Node AUve 
Request (or getting a Echo Response from CGF2 to a Echo Request sent by the GSN) it answers by Node Alive 
Respond. Then the GSN tests with an empty packet (7), retrying continuously if no response, using e.g. increasing 
timeouts (using the old unacknowledged packet's Sequence Number, if the CGFl would consider the packet to be a new 
one (8a) or an already received one (8b) ). According to the response of the CGFl, the GSN gives the CGF2 a command 
to either release (9a) or cancel (9b) the corresponding CDR packet from CGF2. CGF2 then confirms the decision (10), 
and is able to send the CDRs towards the BS (I la). 
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Error handlings: As a default, retransmissions after configurable timeouts are used. If after CGFl communication failure 
the CDR packet sending from GSN to CGF2 does not succeed, the GSN tries to use CGF3 as the intermediate CDR 
packet storaging entity, etc. If the acknowledgement (10) is not got by the GSN for its message (9a) or (9b), the GSN 
will retransmit the message (9a) or (9b) continuously and persistently, using e.g. increasing time intervals. An alarm 
should be sent to the O&M system if a communication link goes down. It shall be possible to release/cancel CDR 
packets from CGFs and unacknowledged sequence numbers from GSNs by O&M operations if permanent GSN-CGF 
link failures would occur. The buffers containing Sequence Numbers of potentially duplicated packets and the buffers 
containing the numbers of unacknowledged CDR packets must be kept up to date (with CDR packet transfers) using 
atomary transaction mechanisms. If the GSN-CGFl communication link is down, any new CDRs generated by the GSN 
are sent to a properly working CGF2, instead of the CGFl. 



8.b) Req. nel. to poss. dupl. packet already fulfilled 
8.a) Request Accepted 

7. Send Data Record Packet: potdupl., emp 
6. Node Alive Response 




5. Node Alive Request 



2. ( No response to GSN) 
1. Send Data Record Packet. 




3. Send Data Record Packet: pot.dupl 



4. Request Accepted 



9.a) Release Data Record Packet 



9.b) Cancel Data Record Packet 



10. Request Accepted 



2.b) CDRs 











Billing System 


CDRs 







11. a) CDRs 




Figure 14: General CGF redundancy messaging scheme 



A more detailed description of the CGF redundancy mechanism: 

Due to a network failure or node failure, a CGF might not send a response within the configured timeout period to a 
request it got from a GSN. As a first attempt, retries of requests are to be used as defined in 09.60, if the response is not 
received in the configured time. 

If a CDR generating node loses its connection to the CGF unexpectedly, it may send the CDRs to the next CGF in the 
priority list. If the CGF changes, the GSN can continue sending CDRs to different CGF nodes, depending on which CGF 
has been configured as the receiver of CDRs for a particular PDP context. 
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Sequence number buffers: The GSN might lose its connection to its primary CGF due to a Hnk failure or CGF going 
down. In this kind of redundancy condition the GSN attempts to redirect the CDR traffic to a secondary CGF (after 
possible retries have failed). The GSN maintains an internal buffer for Sequence Numbers of requests not yet 
successfully responded by the primary CGF, for the case that it may become capable of communicating to the primary 
CGF at a later date. The GSN will send the not responded Data Record Packets (DRPs) to the secondary CGF, and the 
GSN maintains also a buffer for the Sequence Numbers related to those DRPs that have been temporarily stored to this 
secondary CGF. (If the communication towards the secondary CGF would not work, the transfer of possibly duplicated 
DRPs and Sequence Number bookkeeping would be done for a tertiary CGF etc.) Also the CGFs maintain Sequence 
Number buffers for each of their GSN links. The Sequence Numbers may in future be needed in relation to the possibly 
duplicated CDRs that the CGFs have got from the GSN(s). The Sequence Numbers are stored to wait for a final decision 
to release them towards the BS (if the primary CGF had not received successfully the packets originally sent by a GSN) 
or to cancel them (if the primary CGF had received and processed successfully the originally by GSN sent packets). 

The GSN is able to cancel (or release for transfer towards the BS) CDR packets sent to a secondary CGF if the primary 

CGF becomes available for service. To make the right decision the GSN first sends an empty test packet with the 'Send 
possibly duplicated Data Record Packet' Packet Transfer Command to the primary CGF, using a previously not 
responded Sequence Number. 

In case that the empty test packet to the primary CGF which was temporarily down (or to which the link was down) is 
responded with the Cause value "Request Accepted", the GSN will release the corresponding CDRs waiting for final 
decision in the secondary CGF, towards the Bilhng System with the Packet Transfer Command 'Release Data Record 
Packet'. 

If the primary CGF responses this test message with the Cause value "Request related to possibly duplicated packets 
already fulfilled", the GSN will cancel the corresponding CDRs waiting for final decision in the secondary CGF, using 
the Packet Transfer Command 'Cancel Data Record Packet' . 

To enable that a GSN failure (destroying its Sequence Number buffers per each CGF link for non-responded requests or 
possibly duplicated packets) would not cause CDR packets to stay forever in the temporary decision waiting buffers of 
CGFs, there should also be O&M means of emptying those CGF buffers. 

There shall be a also configurable parameter in the CGF for making the final decision as to whether or not it is able to 
send the CDRs to the billing system for the case where the backup buffering mechanism in the GSN could not be used 
until the end of the messaging sequence related to a certain CDR packet has completed. This way the operator can : 

Select that the GSNs and CGFs take care of duplicate prevention and the BS is not required to do duplicate checking 

due to possible duplicates caused by GPRS node redundancy. 

A) Select that BS performs the duplicate prevention. To do this in the most effective way, the CGF may include an 
additional flag linked to possibly duplicated CDRs sent to BilUng System, that they have not been released by a GSN 
for BS use (or use special kind of file name if a file protocol is used between CGF and BS). This means that the BS 
has somewhat more processing work to do, but the BS would anyway get a duphcate free end result. CGF is in this 
case always authorised to forward CDRs towards the BS, also when they contain possibly duplicated data. For this 
case the CGFs may also have a configurable flag that Data Record Packet Cancel/Release operations are not needed. 

7.3.4.5.2 Information Elements in Data Record Transfer Request 

Table 16: Information elements in a Data Record Transfer Request 



Information element 


Presence requirement 


Packet Transfer Command 


Mandatory 


Data Record Packet 


Conditional 


Sequence Numbers of 
Released Packets 


Conditional 


Sequence Numbers of 
Cancelled Packets 


Conditional 


Private Extension 


Optional 



7.3.4.5.3 Packet Transfer Command IE 

The value of the Packet Transfer Command in its information element tells the nature of the message: 
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1 = 'Send Data Record Packet' 

2 = 'Send possibly duplicated Data Record Packet' 

3 = 'Cancel Data Record Packet' 

4 = 'Release Data Record Packet' 

The following describes the usage of each Packet Transfer Command. 

1) Send Data Record Packet. This is used for the normal CDR sending, and it is the usual Packet Transfer Command, 
other commands being used only in error recovery cases. Of the conditional lE's, the "Data Record Packet" is present in 
the message. 

2) Send possibly duplicated Data Record Packet. When the CDR packet is directed to a secondary CGF (by a CDR 
generating node) because the currently used CGF not working or the CDR transfer is not working properly, then this 
Packet Transfer Command is used instead of the normal 'Send Data Record Packet'. Of the conditional IBs, the Data 
Record Packet" is present in the message, when sending the message to a CGF acting as temporary storage, when the 
original primary CGF could not be contacted. 

3) Cancel Data Record Packet. Of the conditional lE's, the "Sequence Numbers of Cancelled Packets" is present in the 
message. 

4) Release Data Record Packet. Of the conditional IE' s, the "Sequence Numbers of Released Packets" is present in the 
message. 



Bits 

Octets 8 7 6 5 4 3 2 1 

1 I Type = 250 (Decimal) 

o Packet Transfer Command 



Figure 15: Packet Transfer Command information eiement 

After the CGF has received the Packet Transfer Command 'Release Data Record Packet' with the Sequence Number(s) 
for earlier sent 'Send possibly dupUcated Data Record Packet' command(s), it can consider itself authorised to send the 
Data Record Packets previously marked as possibly duphcated towards the Bilhng System as normal (not duplicated) 
CDRs. 

7.3.4.5.4 Data Record Packet IE 

The Data Record Packet element, which is present conditionally if the Packet Transfer Command is 'Send Data Record 
Packet' or 'Send possibly duplicated Data Record Packet', may contain one or more data records. The format of the 
records is ASN.l or another format, identified by the Data Record Format. The Data Record Format Version numbering 
starts from 1. 
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Octets 
1 

2...3 
4 
5 

6...7 
8...9 
10.. .n 

X...X+1 

x+2...y 



Bits 
5 



Type = 252 (Decimal) 



Length 



Number of Data Records 



Data Record Format 



Data Record Format Version 



Lengtin of Data Record 1 



Data Record 1 



Length of Data Record N 



Data Record N 



Figure 16: Data Record Packet information element 



7.3.4.5.5 



Sequence Numbers of Released Packets IE 



The Sequence Numbers of Released Packets is present if the Packet Transfer Command is 'Cancel Data Record Packet'. 
The format of the information element is described below: 



Octets 
1 

2.. .3 

4.. .5 

n...n+1 



Bits 

5 



Type = 249 



Length 



Sequence Number 1 



Sequence Number N 



Figure 17: Sequence Numbers of Released Packets information element 



7.3.4.5.6 



Sequence Numbers of Cancelled Packets IE 



The Sequence Numbers of Cancelled Packets information element contains the IE Type, Length and the Sequence 
Number(s) (each 2 octets) of the cancelled Data Record Transfer Request(s). It is present if the Packet Transfer 
Command is 'Cancel Data Record Packet'. 
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Octets 
1 

2. ..3 
4...5 

n...n+1 



Bits 

6 5 4 3 2 



Type = 250 



Length 



Sequence Number 1 



Sequence Number N 



Figure 18: Sequence Numbers of Cancelled Packets information element 

7.3.4.5.7 Private Extension IE 

The optional Private Extension contains vendor or operator specific information. 



7.3.4.6 Data Record Transfer Response 

The message shall be sent as a response of a received Data Record Transfer Request. Also, several Data Record 
Transfer Requests can be responded by a single Data Record Transfer Response. 

Table 17: Information elements in a Data Record Transfer Response 



Information element 


Presence requirement 


Cause 


IVIandatory 


Requests Responded 


IVIandatory 


Private Extension 


Optional 



The Cause value is the same (whatever the value) for all those messages responded by that particular Response. 

Possible Cause values are: 

- "Request Accepted" 

- "No resources available" 
"Service not supported" 

- "System failure" 
"Mandatory IE incorrect" 
"Mandatory IE missing" 
"Optional IE incorrect" 

- "Invalid message format" 

- "Version not supported" 

- "Request not fulfilled" 
"Request already fulfilled " 

- "Request related to possibly duplicated packet already fulfilled" 



The Requests Responded information element contains the IE Type, Length and the Sequence Numbers (each 2 octets) 
of the Data Record Transfer Requests. 
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Octets 
1 

2. .3 
4..5 

n...n+1 



Bits 

6 5 4 

Type = 250 
Length 

Sequence Number 1 



Sequence Number 2 



Figure 19: Requests Responded information element 

The optional Private Extension contains vendor or operator specific information. 

Depending on the Cause value severity and general occurrence frequency, the node that sent the corresponding Data 
Record Transfer Request, may start to direct its CDRs to another CGF. 



7.3.4.7 Examples of GTP' messaging cases 

The following example cases represent the three different key Data Record Transfer Request/Response messaging 
related CDR packet handling schemes: 

Case 1): The normal CDR packet transfer: 

GSN sends successfully a CDR packet to the CGF, and since the GSN gets a response (Request Accepted) 
for the Data Record Transfer Request, there is no need to revert to the CGF redundancy mechanism and 
redirect the CDR packet traffic flow to an other CGF. 

Case 2): The GSN-CGFl cormection breaks before a successful CDR reception: 

In this example case the CDR packet sent by the GSN is lost before it is received by the CGFl. (The loss 
might be caused by a link failure or e.g. a major CGFl failure.) 

Case 3): The GSN-CGFl connection breaks after a successful CDR reception: 

In this example case the CDR packet sent by the GSN is received correctly by the CGFl and moved to its 
non- volatile memory (or even to the next NE in the communication chain). Anyhow, the GSN-CGFl 
communication stops in this example case working before the GSN gets the positive response (Data 
Record Transfer Response: Request Accepted) that would acknowledge that the CDR packet was 
successfully received by CGFl. 

The next three subchapters describe in more detail each of the key Data Record Transfer Request/Response messaging 
schemes. 
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7.3.4.7.1 



Case 1 : The normal CDR packet transfer 



The following figure represents the default mode of CDR transfer from the CDR generating entities (GSNs) to the CDR 
packet collecting entities (CGFs). 




1. Data Record Transfer 
Request: Send Data 
Record Packet 



3. Data Record Transfer 
Response: Request 
Accepted 



CGF's 
volatile memory 



Non-volatile 
CGF memory 



2. CDRs are stored 
in a secure way 



4. < Succesfully 
sent CDRs are deleted 
from the GSN 
buffers > 



Figure 20: A normal CDR transfer process between a GSN and CGF 

1) The CDR generating entity (here the GSN symbolises either SGSN or GGSN) sends CDR(s) in a packet to CGF 
(that is the current primary Charging Gateway Functionality for the specific CDR generating node, "CGFl"). The 
sending is performed by using the Data Record Transfer Request message, with the Packet Transfer Command IE 
having the value 'Send Data Record Packet' . 

2) The CGF opens the received message and stores the packet contents in a safe way (to e.g. a redundant RAM 
memory unit or a mirrored non- volatile memory or even to another node). 

3) The CDR receiving entity (CGF) sends confirmation of the successful packet reception to the CDR generating 
node (GSN). The confirmation is performed by using the Data Record Transfer Response message, with the 
Cause value being 'Request Accepted' . 

4) After the positive response 'Request Accepted' is received by the GSN, it may delete the successfully sent CDRs 
from its send buffer. 

The general principle of GTP' to retransmit the request if the response has not been received within a configurable time- 
out limit, is also followed here in point 1). The maximum amount of retries is a configurable value. 

7.3.4.7.2 Case 2: The GSN-CGF1 connection breaks before a successful CDR reception 

The following figure describes the exceptional case when the CDR transfer from a CDR generating entity (GSN) to the 
primary CDR packet collecting entity (CGFl) fails in a way that the CGFl is not able to store the CDR packet sent by 
the GSN. (The reason for the failure in packet transfer may be e.g. a hnk failure between the GSN and CGFl, or a 
capacity exhausting error in the storage device of CGFl, or a general CGFl system failure or CGFl maintenance break.) 
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7. < CDRs are 
deleted 
from GSN 
buffers > 




1 . Data Record Transfer 
Request: Send Data 
Record Packet 



3. < No positive response to GSN even to resent requests > 



4. Data Record Transfer 
duplicated Data 



Request: Send possibly 
Record Packet 



CDR 



5. <CGF2 stores the 

6. Data Record Transfet 



8. Node Alive Request 



9. Node Alive Response: Request Accepted 



10. Data Record Transfer Request: Send possibly 
duplicated Data RecOT d Packet (empty) 




2. < CDRs not stored to 
nor sent to 



non- volatile memory 
postprocessing > 



packet contents to its buffer for pot. dupl. packets 
Response: Request Accepted 



1 1 . Data Record Transfe ^ Response: Request Accepted 



12. Data Record Transfer Request: Release Data Recortl Packet 

► 



14. Data Record Transft;r Response: Request Accepted 



CDR 
postprocessing 



13. CDRs 



Figure 21 : Duplicate prevention case : CDR sending via CGF1 liad not succeeded 

1) The CDR generating entity (GSN) sends CDR(s) in a packet to CGF (that is the current primary Charging 
Gateway Functionality for the specific CDR generating node, "CGFl"). The sending is performed by using the 
Data Record Transfer Request message, with the Packet Transfer Command IE having the value 'Send Data 
Record Packet'. 

2) Due to a failure in the GSN-CGFl communication link of CGFl, the CGFl is not able to store the packet sent by 
the GSN in a safe way (to e.g. a redundant RAM memory imit or a mirrored non-volatile memory or to another 
node). 
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3) Therefore the GSN is not able to get a response (or it could alternatively get a negative response like "No 
resources available" as the Cause value in the Data Record Transfer Response message). 

4) (The GSN may now first test the GSN-CGF2 hnk by a Echo Request message, that the CGF2 would respond by 
the Echo Response.) Then the GSN sends the same CDR packet that could not be sent to CGFl to the next CGF 
in its CGF preference list (here CGF2) using the Data Record Transfer Request message, with the Packet 
Transfer Command IE having the value 'Send possible duplicated Data Record Packet'. 

5) As the connection to the CGF2 is working, the CGF2 is able to process the CDR packet. Since the packet was 
marked by the sending GSN to be potentially duplicated, it is stored into the CGF2, but not yet sent forward 
towards the Billing System. 

6) The CGF2 sends confirmation of the successful packet reception to the GSN. The confirmation is performed by 
using the Data Record Transfer Response message, with the Cause value being 'Request Accepted' 

7) The GSN can now delete the now successfully sent (potentially duplicated) CDRs from its CDR buffer (but it 
keeps the sequence number(s) of the sent potentially duphcated packet(s) in a buffer dedicated for that. 

8) When CGFl is recovering after a system reboot, it sends a Node Alive Request message to the configured peer 
GSN(s), and so the GSN notices that it can again successfully communicate with the CGFl. (The GSN may also 
detect this by using the Echo Request messages, which would be answered by CGFl by the Echo Response 
message.) 

9) GSN acknowledges the CGFl by Node Alive Response message. 

10) For the earlier unacknowledged Data Record Transfer Request message(s), the GSN sends CGFl empty test 
packet(s) (with no CDR payload in the Data Record Packet IE but just the other parts of the message frame). 

11) CGF1 responds with Data Record Transfer Response message, with the Cause value being 'Request Accepted', 
because in this example case CGFl had lost the communication capability towards GSN before storing the 
previously received (and by CGFl unacknowledged) CDR packet. 

12) Now GSN knows that the CGFl had not originally been able to process and forward the original version of the 
CDR packet from the GSN, and it indicates CGF2 that CGF2 can send the CDR packet(s) related to the 
previously unacknowledged GTP' Sequence Number(s) to postprocessing. Those packets' Sequence Numbers 
are indicated in the Sequence Numbers of the Released Packets IE. 

13) CGF2 shall now be able to send the released packets towards postprocessing. 

14) CGF2 responds with Data Record Transfer Response message, with the Cause value being 'Request Accepted'. 

After all the potentially duplicated packets are cleared form CGF(s), the GSN can continue in normal way the transfer of 
CDRs. 

7.3.4.7.3 Case 3: The GSN-CGF1 connection breaks after a successful CDR reception 
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7. < CDRs are 
deleted from 
GSN buffers > 




1 . Data Record Transfer 
Request: Send Data 
Record Packet 



3. < No positive response to GSN, even to resent requests > 



4. Data Record Transfer Request: Send possibly duplicated Data Record Packet 



5. < CGF2 stores the Cr>R 
6. Data Record Transf ;r 



8. Node Alive Request 



9. Node Alive Response 



10. Data Record Transfer 
duplicated Data RecoM 



1 1 . Data Record Transfer 
to possibly duplicated 



13. <The 
14. Data Record TransJ'er 




< 2. CDR packet contents 
CGFl memory or 



sent 



packet contents to its buffer for pot. dupl. packets ^ 
Response: Request Accepted 



Request: Send possibly 
Packet (empty) 



Response: Request related 
packets already fulfilled 



12. Data Record Transfer Request: Cancel Data R(;cord Packet 



cancelled packet(s) are deleted in CGF2 > 
Response: Request Acc(^pted 



CDR 
postprocessing 



1 is stored to non- volatile 
; for postprocessing > 



Figure 22: Duplicate prevention case : CDR sending via CGF1 liad succeeded 

1) The CDR generating entity (GSN) sends CDR(s) in a packet to CGF (that is the current primary Charging 

Gateway Functionality for the specific CDR generating node, "CGFl"). The sending is performed by using the 
Data Record Transfer Request message, with the Packet Transfer Command IE having the value 'Send Data 
Record Packet'. 

2) The CGFl is able to store the packet sent by the GSN in a safe way (to e.g. a redundant RAM memory unit or a 
mirrored non-volatile memory or to another node). 
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3) Since the GSN-CGFl communication connection is now broken, the GSN is not able to get the response 
"Request Accepted" as the Cause value in the Data Record Transfer Response message. 

4) Then the GSN sends the same CDR packet that could not be sent to CGFl to the next CGF in its CGF preference 
list (here CGF2) a Data Record Transfer Request message, with the Packet Transfer Command IE having the 
value 'Send possible duplicated Data Record Packet'. (That sending may be preceeded by the testing of the GSN- 
CGF2 Unk by a Echo Request message, that the CGF2 would respond by the Echo Response.) 

5) As the connection to CGF2 is working, CGF2 is able to process the CDR packet. Since the packet was marked by 
the sending GSN to be potentially duplicated, it is stored in CGF2, but not yet sent forward towards the post 
processing or Billing System. 

6) The CGF2 sends confirmation of the successful packet reception to the GSN. The confirmation is performed by 
using the Data Record Transfer Response message, with the Cause value being 'Request Accepted' 

7) The GSN can now delete the now successfully sent (potentially duplicated) CDRs from its CDR buffer (but it 
keeps the sequence number(s) of the sent potentially dupUcated packet(s) in a buffer dedicated for that. 

8) When CGFl is recovering after a system reboot, it sends a Node Alive Request message to the configured peer 
GSN(s), and so the GSN notices that it can again successfully communicate with the CGFl. (The GSN may also 
detect this by using the Echo Request messages, which would be answered by CGFl by the Echo Response 
message.) 

9) GSN acknowledges the CGFl by Node Alive Response message. 

10) For the earlier unacknowledged Data Record Transfer Request message(s), the GSN sends CGFl empty test 
packet(s) (with no CDR payload in the Data Record Packet IE but just the other parts of the message frame). 

11) CGF1 responds with Data Record Transfer Response message, with the Cause value being 'Request related to 
possibly duplicated packets already fulfilled', because in this example case CGFl had lost the communication 
capability towards GSN after storing the previously received (and by CGFl imacknowledged) CDR packet. 

12) Now GSN knows that the CGFl had originally been able to process and forward the original version of the CDR 
packet from the GSN, and it indicates CGF2 that CGF2 can cancel the CDR packet(s) related to the previously 
imacknowledged GTP' GSN-CGFl Sequence Number(s). Those packets' Sequence Numbers are indicated in the 
Sequence Numbers of the Cancelled Packets IE. 

13) CGF2 shall now delete the cancelled packet(s) from its buffer for potentially duplicated packets. 

14) CGF2 responds with Data Record Transfer Response message, with the Cause value being 'Request Accepted'. 

After all the potentially duplicated packets are cleared form CGF(s), the GSN can continue in normal way the transfer of 
CDRs. 



7.4 Data Recorcd Formats used in GTP' 

The format of the CDRs sent between the GPRS network elements that generate the CDRs and the CGF are defined by 
the Data Record Format of Data Record Packet information element. In addition to 1 standard format (ASN.l), there are 
private formats. 



7.4.1 ASN.1 format 

See clause 8 and the ASN.l language descriptions for the definitions. BER (Basic Encoding Rules) provides the transfer 
syntax for abstract syntax defined in ASN.l. The Data Record Format code for ASN.l is 1. 



7.4.2 Other formats 

The physical CDR format can also be a private one. The 
for private (implementation specific) use. 



Record Format identifiers 11. ..50 (decimal) are reserved 
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7.5 CGF - BS Protocol Interface 

7.5.1 The transfer protocols at CGF - BS interface 

This document gives several recommendations for the main protocol layers for the Charging Gateway Functionality - 
Billing System interface protocol stack. These recommendations are not strictly specified features, since there are a lot 
of variations among the existing Billing Systems. The recommendations are FT AM protocol on X.25 or TCP/IP, and 
FTP over TCP/IP. 

7.5.2 The format of the CDRs at CGF - BS interface 

The contents of the CDRs sent between the CGF and the Billing System are defined by the ASN. 1 language in the GPRS 
charging specifications. Other CDR contents or formats are possible if the CGF provides processing functionaUty for the 
CDRs. 



8 Charging Data Record Structure 
8.1 ASN.1 definitions for CDR information 

Within the current GSM I2-series of specifications the ASN. 1 definitions are based on X.208 [40] which has been 
superseded by X.680. This newer version not only includes new features but also removes some that were present in 
X.208. It was agreed that where possible, the GPRS work would be based on those ASN.l features that were common to 
both. However, where necessary, the new features in X.680 [41] be used in some places. X.208 feature that are no 
longer in X.680 will not be used. 

Changes (enhancements) in GSM1205-DataTypes : 



Cal 
{ 



lEventRecordType 


: := INTEGER 


moCallRecord 


(0), 


mtCallRecord 


(1), 


roamingRecord 


(2) , 


incGatewayRecord 


(3) , 


outGatewayRecord 


(4), 


transitCallRecord 


(5), 


moSMSRecord 


(6) , 


mtSMSRecord 


(7), 


moSMSIWRecord 


(8), 


mtSMSGWRecord 


(9), 


ssActionRecord 


(10) , 


hlrlntRecord 


(11) , 


locUpdateHLRRecord 


(12) , 


locUpdateVLRRecord 


(13) , 


commonEquipRecord 


(14) , 


moTraceRecord 


(15) , 


mtTraceRecord 


(16) , 


termCAMELInt Record 


(17) , 


sgsnPDPRecord 


(18) , 


ggsnPDPRecord 


(19) , 


sgsnMMRecord 


(20) , 


sgsnSMORecord 


(21) , 


sgsnSMTRecord 


(22) 



} 

GPRS_Charging-DataTypes { ... } 
DEFINITIONS IMPLICIT TAGS ::= 
BEGIN 

— EXPORTS everything 
IMPORTS 

Cellld, Diagnostics, CallDuration, ManagementExtensions, TimeStamp, MSISDN, LocationAreaCode, 

MessageRef erence, RecordingEntity, SMSResult 

FROM GSM1205-DataTypes { ccitt (0) identif ied-organization (4) etsi(O) mobileDomain (0) gsmOperation- 
Maintenance (3) moduleld (3) gsm-12-05 (5) Inf ormationModel (0) asnlModule (2) 1 } 
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AddressString, ISDN-AddressString, IMSI, IMEI 

FROM MAP-CommonDataTypes { ccitt identif ied-organization (4) etsi(O) mobileDomain (0) gsmNetworkId 
(1) moduleld (3) map-CommonDataTypes (18) version2 (2) } 



Ob ject Instance 

FROM CMIP-1 { joint-iso-ccitt ms(9) cmip(l) versionl (1) protocol (3)} 
ManagementExtension 

FROM Attribute-ASNlModule {joint-iso-ccitt ms(9) smi(3) part2 (2) asnlModule (2) 1} 
AE-title 

FROM ACSE-1 {joint-iso-ccitt association-control (2) abstract-syntax ( 1 ) apdus(O) version(l) } ; 

— Note that the syntax of AE-title to be used is from 

— CCITT Rec. X.227 / ISO 8650 corrigendum and not "ANY" 



— CALL AND EVENT RECORDS 



Cal IE vent Re cord 



CHOICE 



sgsnPDPRecord 

ggsnPDPRecord 

sgsnMMRecord 

sgsnSMORecord 

sgsnSMTRecord 



[0] SGSNPDPRecord, 

[1] GGSNPDPRecord, 

[2] SGSNMMRecord, 

[3] SGSNSMORecord, 

[4] SGSNSMTRecord 



GGSNPDPRecord 



SET 



recordType [0] 

networklnitiation [1] 
anonymousAccess Indicator 

servedlMSI [3] 

ggsnAddress [4] 

chargingID [5] 

sgsnAddress [6] 

accessPointName [7] 

pdpType [8] 

servedPDPAddress [9] 

remotePDPAddress [10] 

dynamicAddressFlag [11] 

listOfTraf f icVolumes [12] 

recordOpeningTime [13] 

duration [14] 

causeForRecClosing [15] 

diagnostics [16] 

recordSequenceNumber [17] 

nodelD [18] 

recordExtensions [19] 

localSequenceNumber [20] 



CallEventRecordType, 

NetworklnitiatedPDPContext OPTIONAL, 
[2] BOOLEAN OPTIONAL, 
IMSI, 

GSNAddress, 
ChargingID, 

SEQUENCE OF GSNAddress, 

AccessPointName, 

PDPType, 

PDPAddress, 

SEQUENCE OF PDPAddress OPTIONAL, 

DynamicAddressFlag OPTIONAL, 

SEQUENCE OF ChangeOf CharCondition, 

Time St amp, 

CallDuration, 

CauseForRecClosing, 

Diagnostics OPTIONAL, 

INTEGER OPTIONAL, 

Node ID OPTIONAL, 

ManagementExtensions OPTIONAL, 

LocalSequenceNumber OPTIONAL 



SGSNMMRecord 
{ 



SET 



recordType [0] 

servedlMSI [1] 

servedlMEI [2] 

sgsnAddress [3] 

msNetworkCapability [4] 

routingArea [5] 

locationAreaCode [6] 

cellldentity [7] 

changeLocation [8] 

recordOpeningTime [9] 

duration [10] 

sgsnChange [11] 

CauseForRecClosing [12] 

diagnostics [13] 

recordSequenceNumber [14] 

nodelD [15] 

recordExtensions [16] 

localSequenceNumber [17] 



CallEventRecordType, 
IMSI , 

IMEI OPTIONAL, 
GSNAddress, 

MSNetworkCapability OPTIONAL, 
RoutingAreaCode OPTIONAL, 
LocationAreaCode OPTIONAL, 
Cellld OPTIONAL, 

SEQUENCE OF ChangeLocation OPTIONAL, 
TimeStamp, 

CallDuration OPTIONAL, 

SGSNChange OPTIONAL, 

CauseForRecClosing, 

Diagnostics OPTIONAL, 

INTEGER OPTIONAL, 

NodelD OPTIONAL, 

ManagementExtensions OPTIONAL, 

LocalSequenceNumber OPTIONAL 



SGSNPDPRecord 



SET 
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recordType [0] 

networklnitiation [1] 
anonymousAccess Indicator 

servedlMSI [3] 

servedlMEI [4] 

sgsnAddress [5] 

msNetworkCapability [6] 

routingArea [7] 

locationAreaCode [8] 

cellldentity [9] 

chargingID [10] 

ggsnAddressUsed [11] 

accessPointName [12] 

pdpType [13] 

servedPDPAddress [14] 

listOfTraf ficVolumes [15] 

recordOpeningXime [16] 

duration [17] 

sgsnChange [18] 

causeForRecClosing [19] 

diagnostics [20] 

recordSequenceNumber [21] 

nodelD [22] 

recordExtensions [23] 

localSequenceNumber [24] 



CallEventRecordType, 

NetworklnitiatedPDPContext OPTIONAL, 
[2] BOOLEAN OPTIONAL, 
IMS I , 

IMEI OPTIONAL, 
GSNAddress, 

MSNetworkCapability OPTIONAL, 
RoutingAreaCode OPTIONAL, 
LocationAreaCode OPTIONAL, 
Cellld OPTIONAL, 

ChargingID, 

GSNAddress, 

AccessPointName, 

PDPType, 

PDPAddress, 

SEQUENCE OF ChangeOf CharCondition, 

TimeStamp, 

CallDuration, 

SGSNChange OPTIONAL, 
CauseForRecClosing, 
Diagnostics OPTIONAL, 
INTEGER OPTIONAL, 
NodelD OPTIONAL, 

ManagementExtensions OPTIONAL, 
LocalSequenceNumber OPTIONAL 



SGSNSMORecord 



SET 



recordType [0] 

servedlMSI [1] 

servedlMEI [2] 

servedMSISDN [3] 

msNetworkCapability [4] 

serviceCentre [5] 

recordingEntity [6] 

locationArea [7] 

routingArea [8] 

cellldentity [9] 

messageRef erence [10 

originationTime [11 

smsResult [12 

recordExtensions [13 

nodelD [14 

localSequenceNumber [15 



CallEventRecordType, 
IMS I, 

IMEI OPTIONAL, 

MSISDN OPTIONAL, 

MSNetworkCapability, 

AddressString, 

RecordingEntity, 

LocationAreaCode OPTIONAL, 

RoutingAreaCode OPTIONAL, 

Cellld OPTIONAL, 
] MessageRef erence, 
] TimeStamp, 
] SMSResult OPTIONAL, 
] ManagementExtensions OPTIONAL, 
] NodelD OPTIONAL, 
] LocalSequenceNumber OPTIONAL 



SGSNSMTRecord 



SET 



recordType [0] 

servedlMSI [1] 

servedlMEI [2] 

servedMSISDN [3] 

msNetworkCapability [4] 

serviceCentre [5] 

recordingEntity [6] 

locationArea [7] 

routingArea [8] 

cellldentity [9] 

originationTime [10] 

smsResult [11] 

recordExtensions [12] 

nodelD [13] 

localSequenceNumber [14] 



CallEventRecordType, 
IMS I, 

IMEI OPTIONAL, 
MSISDN OPTIONAL, 
MSNetworkCapability, 
AddressString, 
RecordingEntity, 
LocationAreaCode OPTIONAL, 
RoutingAreaCode OPTIONAL, 
Cellld OPTIONAL, 

TimeStamp, 

SMSResult OPTIONAL, 

ManagementExtensions OPTIONAL, 

NodelD OPTIONAL, 

LocalSequenceNumber OPTIONAL 



— OBJECT IDENTIFIERS 



gsml205InformationModel OBJECT IDENTIFIER ::= 

{ ccitt (0) identif ied-organization (4) etsi (0) mobileDomain (0) 
gsm-Operation-Maintenance (3) gsm-12-05 (5) inf ormationModel (0) } 

gsml205ASNlModule OBJECT IDENTIFIER ::= 
( gsml205Inf ormationModel asnlModule (2 ) } 

gsml205ManagedObjectClass OBJECT IDENTIFIER : := 

{ gsml205Inf ormationModel managedOb jectClass (3) } 
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gsml205Package OBJECT IDENTIFIER : := 

{ gsml205Inf ormationModel package (4) } 

gsml205NameBinciing OBJECT IDENTIFIER :: = 

{ gsml205Inf ormationModel nameBinding ( 6) } 

gsml205Attribute OBJECT IDENTIFIER ::= 

{ gsml205Inf ormationModel attribute (7) } 

gsml205Action OBJECT IDENTIFIER ::= 

{ gsml205Inf ormationModel action (9) } 

gsml205Notification OBJECT IDENTIFIER ::= 

{ gsml205Inf ormationModel notification (10) } 



— COMMON DATA TYPES 



AccessPointName : := lASString ( SIZE ( 1 . . 63 ) ) 

— logical (domain) name in "dot" representation 

— see GSM 09.60 



CauseForRecClosing ::= INTEGER 



— in GGSN the value sGSNChange should be used for partial record 

— generation due to SGSN Address List Overflow 

— cause codes to 15 are defined in GSM12.05 as ' CauseForTerm' (cause for termination) 



normalRelease (0), 

abnormalRelease (4), 

volumeLimit (16), 

timeLimit (17), 

sGSNChange (18), 

maxChangeCond (19), 



managementlntervention (20) 

} 



ChangeCondition : := ENUMERATED 
{ 

qoSChange (0), 
tariffTime (1), 
recordClosure (2) 

} 



ChangeOfCharCondition : := SEQUENCE 
— used in PDF context record only 



qosRequested 


[1] 


QoSInf ormation OPTIONAL 


qosNegotiated 


[2] 


QoSInformation OPTIONAL 


dataVolumeGPRSUplink 


[3] 


DataVolumeGPRS, 


dataVolumeCPRSDownlink 


[4] 


DataVolumeGPRS, 


ChangeCondition 


[5] 


ChangeCondition, 


changeTime 


[6] 


TimeStamp 



ChangeLocation : := SEQUENCE 

— used in SGSNMMRecord only 

{ 

locationAreaCode [0] LocationAreaCode, 

routingAreaCode [1] RoutingAreaCode, 

cellld [2] CelllD OPTIONAL, 

changeTime [3] TimeStamp 

} 



ChargingID : := INTEGER (0 .. 4294967295) 

— generated in GGSN, part of PDP context, see TS GSM 03.60 

— 0.. 4294967295 is equivalent to 0.. 2**32-1 



DataVolumeGPRS ::= INTEGER 

— The volume of uncompressed data transferred in octets. 
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DynamicAddressFlag ::= BOOLEAN 

ETSIAddress ::= AddressString 

— first octet for nature of address, and numbering plan indicator (3 for X.121) 
— other octets TBCD 

— See TS GSM 09.02 

GSNAddress : := IPAddress 
IPAddress : := CHOICE 

iPBinaryAddress IPBinaryAddress, 

iPTextRepresentedAddress IPTextRepresentedAddress 

PBinaryAddress : := CHOICE 

iPBinV4Address [0] OCTET STRING (SIZE (4)), 

iPBinV6Address [1] OCTET STRING (SIZE (16)) 

PTextRepresentedAddress ::= CHOICE 

— IP address in the familiar "dot" notation 

iPTextV4Address [2] lASString (SIZE (7 . . 15) ) , 

iPTextV6Address [3] lASString (SIZE (15 . . 45) ) 

} 

LocalSequenceNumber : := INTEGER (0 .. 4294967295) 

— Sequence number of the record in this node 

— 0.. 4294967295 is equivalent to 0.. 2**32-1, unsigned integer in four octets 
MSNetworl<;Capability : := OCTET STRING (SIZE(l)) 

NetworklnitiatedPDPContext ::= BOOLEAN 

— Set to true if PDP context was initiated from network side 

NodelD ::= IA5 string (SIZE ( 1 . . 20 ) ) 

PDPAddress : := CHOICE 
{ 

IPAddress [0] IPAddress, 

eTSIAddress [1] ETSIAddress 

} 

PDPType ::= OCTET STRING (SIZE (2)) 

— OCTET 1: PDP Type Organization 
— OCTET 2 : PDP Type Number 

— See TS GSM 9.60 

QoSDelay : := ENUMERATED 

{ 

— See Quality of service TS GSM 04.08 

delayClassl (0), 

delayClass2 (1), 

delayClass3 (2), 

delayClass4 (3) 



QoSInf ormation : :=SEQUENCE 

{ 

reliability [0] QoSReliability , 

delay [1] QoSDelay, 

precedence [2] QoSPrecedence, 

peakThroughput [3] QoSPeakThroughput, 

meanThroughput [4] QoSMeanThroughput 



QoSMeanThroughput : := ENUMERATED 
{ 

— See Quality of service TS GSM 04.06 
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bestEf f ort 


(0) , 


meanlOOoctetPh 


(1) , 


mean200octetPh 


(2) , 


meanSOOoctetPh 


(3) , 


meanlOOOoctetPh 


(4) , 


mean2000octetPh 


(5) , 


meanSOOOoctetPh 


(6) , 


meanlOOOOoctetPh 


(7) , 


mean20000octetPh 


(8) , 


meanSOOOOoctetPh 


(9) , 


meanlOOOOOoctetPh 


(10) , 


mean200000octetPh 


(11) , 


meanSOOOOOoctetPh 


(12) , 


meanlOOOOOOoctetPh 


(13) , 


mean2000000octetPh 


(14) , 


meanSOOOOOOoctetPh 


(15) , 


meanlOOOOOOOoctetPh 


(16) , 


mean20000000octetPh 


(17) , 


meanSOOOOOOOoctetPh 


(18) 



QoSPeakThroughput : := ENUMERATED 
{ 

— See Quality of service TS GSM 04.08 

unspecified (0) , 

upTolOOOctetPs (1), 

upTo200OctetPs (2), 

upTo400OctetPs (3), 

upTo800OctetPs (4), 

upToieOOOctetPs (5), 

upTo3200OctetPs (6), 

upTo6400OctetPs (7), 

upTol2800OctetPs (8), 

upTo25600OctetPs (9) 

} 



QoSPrecedence : := ENUMERATED 
{ 

— See Quality of service TS GSM 04.08 

unspecified (0) , 

highPriority (1); 

normalPriority (2), 

lowPriority (3) 

} 



QoSReliability : := ENUMERATED 
{ 

— See Quality of service TS GSM 04.08 

unspecif iedReliability (0), 

acknowledgedGTP (1), 

unackGTPAcknowLLC (2), 

unackGTPLLCAcknowRLC (3), 

unackGTPLLCRLC (4), 

unacknowUnprotectedData (5) 

} 



RoutingAreaCode : := OCTET STRING (SIZE(l)) 
— See TS GSM 04.08 — 



SGSNChange : := BOOLEAN 

— present if first record after inter SGSN routing area update 

— in new SGSN 
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Annex A (informative): 
Change history 



This annex lists all phase2+ change requests approved for the present document by ETSI SMG. 



SMG# 


SMG 
tdoc 


SMG6 
tdoc 


VERS 


CR 


RV 


PH 


CAT 


SUBJECT 


Resulting 
Version 


s26 


98-0335 


98p044 


2.0.0 










GSM 12.15 R97 approved at SMG #26 


6.0.0 


s27 


98-0666 


98p051 


6.0.0 


A001 


10 


R98 


B 


Addition of a charging protocol 


7.0.0 




98-0666 


98p057& 
98p058 




A002 




R97 


F 


Clarification to "GPRS charging logical arctiitecture figure" and 
other corrections 




s28 


P-99-177 


6-99-013 


7.0.0 


A004 




R98 


B 


Addition of record identifier. 


7.1.0 




P-99-177 


6-99-014 




A005 




R98 


B 


Addition of new PDP type (PPP) 






P-99-177 


6-99-016 




A007 




R98 


B 


GTP' version management. 






P-99-177 


6-99-017 




A008 




R98 


D 


GPRS charging data collection interface naming. 






P-99-177 


6-99-006 




A010 




R98 


A 


Modification of the parameter "causeForRecciosing" 






P-99-177 


6-99-015 




A011 




R98 


A 


Correction of the parameter "caiiEventRecordXype" 




s29 


P-99-545 




7.1.0 


A009 


3 


R98 


B 


Enhancements to the Charging Protocol 


7.2.0 




P-99-406 


6-99-033 




A012 




R98 


F 


Addition of PDP type OSP:IHOSS 






P-99-406 


6-99-034 




A013 




R98 


F 


Alignment of CDR field names 






P-99-406 


6-99-035 




A014 




R98 


F 


Addition of the Ga interface to the GPRS logical diagram 










7.2.0 










Version 7.21 was produced as a result of a mistake made in the 
chargiong protocol subclause during the production of v7.2.1 
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